From jira-events at lists.jboss.org  Fri Jul  1 00:30:39 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Fri, 1 Jul 2011 00:30:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1162) The missing
 dependences of a deployment are not reported on failure
Message-ID: <260387773.31474.1309494639012.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

The missing dependences of a deployment are not reported on failure
-------------------------------------------------------------------

                 Key: AS7-1162
                 URL: https://issues.jboss.org/browse/AS7-1162
             Project: Application Server 7
          Issue Type: Bug
            Reporter: Stuart Douglas


When a deployment fails due to missing dependencies it does not report which dependencies are actually missing, making it very difficult to debug the underlying problem.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 00:30:39 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Fri, 1 Jul 2011 00:30:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1162) The missing
 dependences of a deployment are not reported on failure
In-Reply-To: <260387773.31474.1309494639012.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1142347796.31476.1309494639111.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas updated AS7-1162:
--------------------------------

    Affects Version/s: 7.0.0.CR1


> The missing dependences of a deployment are not reported on failure
> -------------------------------------------------------------------
>
>                 Key: AS7-1162
>                 URL: https://issues.jboss.org/browse/AS7-1162
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.CR1
>            Reporter: Stuart Douglas
>
> When a deployment fails due to missing dependencies it does not report which dependencies are actually missing, making it very difficult to debug the underlying problem.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 01:01:28 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Fri, 1 Jul 2011 01:01:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1162) The missing
 dependences of a deployment are not reported on failure
In-Reply-To: <260387773.31474.1309494639012.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <343235906.31482.1309496488604.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas commented on AS7-1162:
-------------------------------------

At the very least we should not report on services that have no immediate unavailable dependencies. 

> The missing dependences of a deployment are not reported on failure
> -------------------------------------------------------------------
>
>                 Key: AS7-1162
>                 URL: https://issues.jboss.org/browse/AS7-1162
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.CR1
>            Reporter: Stuart Douglas
>
> When a deployment fails due to missing dependencies it does not report which dependencies are actually missing, making it very difficult to debug the underlying problem.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 02:05:23 2011
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 1 Jul 2011 02:05:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-1341) BARRIER: block only
 multicast, not unicast messages
In-Reply-To: <598570935.29693.1309430483764.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <504659436.31520.1309500323691.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban resolved JGRP-1341.
----------------------------

    Resolution: Done


> BARRIER: block only multicast, not unicast messages
> ---------------------------------------------------
>
>                 Key: JGRP-1341
>                 URL: https://issues.jboss.org/browse/JGRP-1341
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.12.2, 3.0
>
>
> BARRIER is used by the state transfer protocols, to get the digest and the state atomically. However, the digest only keeps track of multicast (=group) messages, so we don't need to block unicast messages !
> This would help us in STREAMING_STATE_TRANSFER: even though we block the BARRIER, the state chunks sent from the state provider to the state requester (when use_default_transport=true) will *not* get blocked with this change !

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 03:25:23 2011
From: jira-events at lists.jboss.org (Daniel Bevenius (JIRA))
Date: Fri, 1 Jul 2011 03:25:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-8551) tests.classpath
 length impacts running tests on Windows
In-Reply-To: <391795239.14003.1287838974702.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1744526355.31579.1309505123935.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Daniel Bevenius updated JBAS-8551:
----------------------------------

    Attachment: build.xml.patch


Attaching new build.xml.patch. Please delete the old one as I was not able to do so. 

Thanks, 

/Daniel

> tests.classpath length impacts running tests on Windows
> -------------------------------------------------------
>
>                 Key: JBAS-8551
>                 URL: https://issues.jboss.org/browse/JBAS-8551
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: No Release
>
>         Attachments: build.xml.patch, build.xml.patch, testsuite-imports.patch, testsuite-imports.patch
>
>
> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-Windows/498/console

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 03:52:23 2011
From: jira-events at lists.jboss.org (Miroslav Novak (JIRA))
Date: Fri, 1 Jul 2011 03:52:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1882) Missing
 jbossweb.jar in JBM test suite
In-Reply-To: <2017882900.21667.1309164625093.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1943590564.31625.1309506743809.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Miroslav Novak commented on JBMESSAGING-1882:
---------------------------------------------

Hi Howard,

now I'm asking just to be sure. jboss-messaging.jar has dependency to jboss-remoting.jar and jboss-remoting.jar has a dependency to jbossweb.jar (which is in classpath in EAP 5.1.1 ER3) so there is no problem for EAP 5.1.1.

Thank you,

Mirek

> Missing jbossweb.jar in JBM test suite
> --------------------------------------
>
>                 Key: JBMESSAGING-1882
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1882
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.8.SP1
>            Reporter: Miroslav Novak
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.8.SP2
>
>         Attachments: jbossweb.jar
>
>
> Hi Howard,
> when I've started clustering tests target then all of them failed because jbossweb.jar is missing. Could you modify our ant scripts to download it and put to classpath when for "tests" target, please.
> Thank you,
> Mirek

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 04:33:24 2011
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Fri, 1 Jul 2011 04:33:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1163) The license of JBoss
 AS itself is not evident in the distribution
Message-ID: <1211201247.31687.1309509204437.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

The license of JBoss AS itself is not evident in the distribution
-----------------------------------------------------------------

                 Key: AS7-1163
                 URL: https://issues.jboss.org/browse/AS7-1163
             Project: Application Server 7
          Issue Type: Task
          Components: Build System
    Affects Versions: 7.0.0.CR1
            Reporter: Dimitris Andreadis
            Assignee: Paul Gier
            Priority: Critical
             Fix For: 7.0.0.Final


When looking in the distribution, it's not evident what is the license of the application server itself.

We have the licenses for the various subsystems in docs/licenses and the docs/licenses/licenses.xml containing entries like

    <dependency>
      <groupId>org.jboss.as</groupId>
      <artifactId>jboss-as-build-config</artifactId>
      <version>7.0.0.CR1</version>
      <licenses>
        <license>
          <name>lgpl</name>
          <url>http://repository.jboss.org/licenses/lgpl-2.1.txt</url>
        </license>
      </licenses>
    </dependency>

But I think we need something more explicit like we had in previous releases.

Maybe a txt file LICENSE.txt either in docs/licenses, or in the top level directory.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 05:18:23 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Fri, 1 Jul 2011 05:18:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1164) add jdbc-driver :
 documentation incomplete or misleading
Message-ID: <2061849607.31723.1309511903626.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

add jdbc-driver : documentation incomplete or misleading
--------------------------------------------------------

                 Key: AS7-1164
                 URL: https://issues.jboss.org/browse/AS7-1164
             Project: Application Server 7
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 7.0.0.CR1
            Reporter: Heiko Rupp


I want to add a jdbc driver to a profile. The driver has been uploaded to /deployment
[domain at localhost:9999 subsystem=datasources] pwd
/profile=default/subsystem=datasources
[domain at localhost:9999 subsystem=datasources] ./jdbc-driver=postgres9:add(driver-name=postgres9,deployment-name=postgresql-9.0-801.jdbc4.jar,driver-class-name=org.postgresql.Driver)
{
    "outcome" => "failed",
    "failure-description" => {"domain-failure-description" => "Operation handler failed: java.util.NoSuchElementException: No child 'driver-module-name' exists"},
    "rolled-back" => true
}

Documentation says:

[domain at localhost:9999 jdbc-driver=h2] :read-operation-description(name=add)                 
{
    "outcome" => "success",
    "result" => {
        "operation-name" => "add",
        "description" => "Adds a new JDBC driver service",
        "attributes" => {
            "driver-name" => {
                "description" => "The symbolic name of this driver used to reference it in the register",
                "type" => STRING,
                "required" => true
            },
            "deployment-name" => {
                "description" => "The name of the deployment unit from which the driver was loaded, if it was loaded from a deployment",
                "type" => STRING
            },
            "driver-module-name" => {
                "description" => "The name of the module from which the driver was loaded, if it was loaded from the module path",
                "type" => STRING
            },
            "module-slot" => {
                "description" => "The slot of the module from which the driver was loaded, if it was loaded from the module path",
                "type" => STRING
            },
            "driver-class-name" => {
                "description" => "The fully qualified class name of the driver's implementation of java.sql.Driver",
                "type" => STRING
            },
            "driver-major-version" => {
                "description" => "The driver's major version number",
                "type" => INT
            },
            "driver-minor-version" => {
                "description" => "The driver's minor version number",
                "type" => INT
            },
            "jdbc-compliant" => {
                "description" => "Whether or not the driver is JDBC compliant",
                "type" => BOOLEAN
            }
        }
    }
}


Here, only the driver-name is required.
For driver-module-name it says "if loaded from module", which I read as "optional".
Obviously from above error message, this is not optional


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 05:38:24 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Fri, 1 Jul 2011 05:38:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1151) Error while
 registering Oracle JDBC Diagnosability MBean
In-Reply-To: <756188351.29161.1309420043598.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <743210207.31752.1309513104351.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefano Maestri resolved AS7-1151.
----------------------------------

    Resolution: Rejected


It's not a bug in our code, but the driver

> Error while registering Oracle JDBC Diagnosability MBean
> --------------------------------------------------------
>
>                 Key: AS7-1151
>                 URL: https://issues.jboss.org/browse/AS7-1151
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMX
>    Affects Versions: 7.0.0.CR1
>            Reporter: Nicklas Karlsson
>
> Deploying the Oracle 11.1 driver jdbc-driver-11.1.0.6.0.jar through the admin console gives a 
> 10:42:15,938 SEVERE [oracle.jdbc] (MSC service thread 1-7) Error while registering Oracle JDBC Diagnosability MBean.: java.lang.NullPointerException
> 	at oracle.jdbc.driver.OracleDriver.registerMBeans(OracleDriver.java:301)
> 	at oracle.jdbc.driver.OracleDriver$1.run(OracleDriver.java:213)
> 	at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_23]
> 	at oracle.jdbc.driver.OracleDriver.<clinit>(OracleDriver.java:209)
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [:1.6.0_23]
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) [:1.6.0_23]
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) [:1.6.0_23]
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:513) [:1.6.0_23]
> 	at org.jboss.as.connector.deployers.processors.DriverProcessor.deploy(DriverProcessor.java:66)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
> 	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_23]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_23]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_23]
> the driver looks registered/enabled, though, this is just an error from the diagnose bean

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 05:38:25 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Fri, 1 Jul 2011 05:38:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1151) Error while
 registering Oracle JDBC Diagnosability MBean
In-Reply-To: <756188351.29161.1309420043598.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1285660259.31761.1309513105106.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefano Maestri reassigned AS7-1151:
------------------------------------

    Assignee: Stefano Maestri


> Error while registering Oracle JDBC Diagnosability MBean
> --------------------------------------------------------
>
>                 Key: AS7-1151
>                 URL: https://issues.jboss.org/browse/AS7-1151
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMX
>    Affects Versions: 7.0.0.CR1
>            Reporter: Nicklas Karlsson
>            Assignee: Stefano Maestri
>
> Deploying the Oracle 11.1 driver jdbc-driver-11.1.0.6.0.jar through the admin console gives a 
> 10:42:15,938 SEVERE [oracle.jdbc] (MSC service thread 1-7) Error while registering Oracle JDBC Diagnosability MBean.: java.lang.NullPointerException
> 	at oracle.jdbc.driver.OracleDriver.registerMBeans(OracleDriver.java:301)
> 	at oracle.jdbc.driver.OracleDriver$1.run(OracleDriver.java:213)
> 	at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_23]
> 	at oracle.jdbc.driver.OracleDriver.<clinit>(OracleDriver.java:209)
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [:1.6.0_23]
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) [:1.6.0_23]
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) [:1.6.0_23]
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:513) [:1.6.0_23]
> 	at org.jboss.as.connector.deployers.processors.DriverProcessor.deploy(DriverProcessor.java:66)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
> 	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_23]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_23]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_23]
> the driver looks registered/enabled, though, this is just an error from the diagnose bean

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 05:47:23 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Fri, 1 Jul 2011 05:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1164) add jdbc-driver :
 documentation incomplete or misleading
In-Reply-To: <2061849607.31723.1309511903626.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1263320569.31777.1309513643905.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Rupp reassigned AS7-1164:
-------------------------------

    Assignee: Brian Stansberry


> add jdbc-driver : documentation incomplete or misleading
> --------------------------------------------------------
>
>                 Key: AS7-1164
>                 URL: https://issues.jboss.org/browse/AS7-1164
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.0.0.CR1
>            Reporter: Heiko Rupp
>            Assignee: Brian Stansberry
>
> I want to add a jdbc driver to a profile. The driver has been uploaded to /deployment
> [domain at localhost:9999 subsystem=datasources] pwd
> /profile=default/subsystem=datasources
> [domain at localhost:9999 subsystem=datasources] ./jdbc-driver=postgres9:add(driver-name=postgres9,deployment-name=postgresql-9.0-801.jdbc4.jar,driver-class-name=org.postgresql.Driver)
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "Operation handler failed: java.util.NoSuchElementException: No child 'driver-module-name' exists"},
>     "rolled-back" => true
> }
> Documentation says:
> [domain at localhost:9999 jdbc-driver=h2] :read-operation-description(name=add)                 
> {
>     "outcome" => "success",
>     "result" => {
>         "operation-name" => "add",
>         "description" => "Adds a new JDBC driver service",
>         "attributes" => {
>             "driver-name" => {
>                 "description" => "The symbolic name of this driver used to reference it in the register",
>                 "type" => STRING,
>                 "required" => true
>             },
>             "deployment-name" => {
>                 "description" => "The name of the deployment unit from which the driver was loaded, if it was loaded from a deployment",
>                 "type" => STRING
>             },
>             "driver-module-name" => {
>                 "description" => "The name of the module from which the driver was loaded, if it was loaded from the module path",
>                 "type" => STRING
>             },
>             "module-slot" => {
>                 "description" => "The slot of the module from which the driver was loaded, if it was loaded from the module path",
>                 "type" => STRING
>             },
>             "driver-class-name" => {
>                 "description" => "The fully qualified class name of the driver's implementation of java.sql.Driver",
>                 "type" => STRING
>             },
>             "driver-major-version" => {
>                 "description" => "The driver's major version number",
>                 "type" => INT
>             },
>             "driver-minor-version" => {
>                 "description" => "The driver's minor version number",
>                 "type" => INT
>             },
>             "jdbc-compliant" => {
>                 "description" => "Whether or not the driver is JDBC compliant",
>                 "type" => BOOLEAN
>             }
>         }
>     }
> }
> Here, only the driver-name is required.
> For driver-module-name it says "if loaded from module", which I read as "optional".
> Obviously from above error message, this is not optional

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 06:27:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 1 Jul 2011 06:27:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1165) Improve error
 message(s) of deployment failures
Message-ID: <797335313.31854.1309516043727.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Improve error message(s) of deployment failures 
------------------------------------------------

                 Key: AS7-1165
                 URL: https://issues.jboss.org/browse/AS7-1165
             Project: Application Server 7
          Issue Type: Enhancement
    Affects Versions: 7.0.0.CR1
            Reporter: jaikiran pai
             Fix For: 7.1.0.Alpha1


The error reporting in 7.0.0.CR1 for deployment failures due to missing dependencies is very complex and almost cannot be understood. Here are a couple of examples:

http://community.jboss.org/message/612943#612943
http://community.jboss.org/message/612555#612555

This needs to be improved in later versions.

I'm marking this as "Fix Version" 7.1.0.Alpha1 because I guess this isn't an easy change to incorporate in 7.0.0.Final. If it's possible to get this in for 7.0.0.Final then please change it accordingly.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 06:47:23 2011
From: jira-events at lists.jboss.org (Marek Schmidt (JIRA))
Date: Fri, 1 Jul 2011 06:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1166) Quit the CLI on EOF
Message-ID: <115625773.31875.1309517243776.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Quit the CLI on EOF
-------------------

                 Key: AS7-1166
                 URL: https://issues.jboss.org/browse/AS7-1166
             Project: Application Server 7
          Issue Type: Feature Request
          Components: CLI
    Affects Versions: 7.0.0.CR1
            Reporter: Marek Schmidt


jboss-admin.sh should behave more like a shell and terminate on EOF (ctrl-D)

The current behavior is quite counter-intuitive and trying to do e.g.

echo "deploy foo.war" | ./jboss-admin.sh --connect 

leads the CLI into an infinite-loop generating infinite number of prompts.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 06:49:23 2011
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Fri, 1 Jul 2011 06:49:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1165) Improve error
 message(s) of deployment failures
In-Reply-To: <797335313.31854.1309516043727.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <479837865.31885.1309517363718.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

SBS JIRA Integration updated AS7-1165:
--------------------------------------

    Forum Reference: http://community.jboss.org/message/612943#612943


> Improve error message(s) of deployment failures 
> ------------------------------------------------
>
>                 Key: AS7-1165
>                 URL: https://issues.jboss.org/browse/AS7-1165
>             Project: Application Server 7
>          Issue Type: Enhancement
>    Affects Versions: 7.0.0.CR1
>            Reporter: jaikiran pai
>             Fix For: 7.1.0.Alpha1
>
>
> The error reporting in 7.0.0.CR1 for deployment failures due to missing dependencies is very complex and almost cannot be understood. Here are a couple of examples:
> http://community.jboss.org/message/612943#612943
> http://community.jboss.org/message/612555#612555
> This needs to be improved in later versions.
> I'm marking this as "Fix Version" 7.1.0.Alpha1 because I guess this isn't an easy change to incorporate in 7.0.0.Final. If it's possible to get this in for 7.0.0.Final then please change it accordingly.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 06:53:23 2011
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Fri, 1 Jul 2011 06:53:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1165) Improve error
 message(s) of deployment failures
In-Reply-To: <797335313.31854.1309516043727.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1091614776.31888.1309517603643.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

SBS JIRA Integration updated AS7-1165:
--------------------------------------

    Forum Reference: http://community.jboss.org/message/612943#612943, http://community.jboss.org/message/612545#612545  (was: http://community.jboss.org/message/612943#612943)


> Improve error message(s) of deployment failures 
> ------------------------------------------------
>
>                 Key: AS7-1165
>                 URL: https://issues.jboss.org/browse/AS7-1165
>             Project: Application Server 7
>          Issue Type: Enhancement
>    Affects Versions: 7.0.0.CR1
>            Reporter: jaikiran pai
>             Fix For: 7.1.0.Alpha1
>
>
> The error reporting in 7.0.0.CR1 for deployment failures due to missing dependencies is very complex and almost cannot be understood. Here are a couple of examples:
> http://community.jboss.org/message/612943#612943
> http://community.jboss.org/message/612555#612555
> This needs to be improved in later versions.
> I'm marking this as "Fix Version" 7.1.0.Alpha1 because I guess this isn't an easy change to incorporate in 7.0.0.Final. If it's possible to get this in for 7.0.0.Final then please change it accordingly.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 07:30:24 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 1 Jul 2011 07:30:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1167) Implement PLAIN SASL
	mechanism
Message-ID: <599658245.31945.1309519824233.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Implement PLAIN SASL mechanism
------------------------------

                 Key: AS7-1167
                 URL: https://issues.jboss.org/browse/AS7-1167
             Project: Application Server 7
          Issue Type: Task
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 7.1.0.Alpha1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 08:11:23 2011
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 1 Jul 2011 08:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-8551) tests.classpath
 length impacts running tests on Windows
In-Reply-To: <391795239.14003.1287838974702.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <417696714.32061.1309522283703.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Shelly McGowan updated JBAS-8551:
---------------------------------

    Attachment:     (was: build.xml.patch)


> tests.classpath length impacts running tests on Windows
> -------------------------------------------------------
>
>                 Key: JBAS-8551
>                 URL: https://issues.jboss.org/browse/JBAS-8551
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: No Release
>
>         Attachments: build.xml.patch, testsuite-imports.patch
>
>
> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-Windows/498/console

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 08:11:23 2011
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 1 Jul 2011 08:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-8551) tests.classpath
 length impacts running tests on Windows
In-Reply-To: <391795239.14003.1287838974702.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1444830182.32064.1309522283777.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Shelly McGowan updated JBAS-8551:
---------------------------------

    Attachment:     (was: testsuite-imports.patch)


> tests.classpath length impacts running tests on Windows
> -------------------------------------------------------
>
>                 Key: JBAS-8551
>                 URL: https://issues.jboss.org/browse/JBAS-8551
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: No Release
>
>         Attachments: build.xml.patch, testsuite-imports.patch
>
>
> http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-Windows/498/console

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 08:18:23 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Fri, 1 Jul 2011 08:18:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1168) improve ds management
 operation test suite
Message-ID: <2083030664.32085.1309522703955.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

improve ds management operation test suite
------------------------------------------

                 Key: AS7-1168
                 URL: https://issues.jboss.org/browse/AS7-1168
             Project: Application Server 7
          Issue Type: Task
            Reporter: Stefano Maestri
            Assignee: Stefano Maestri
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 08:18:24 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Fri, 1 Jul 2011 08:18:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1162) The missing
 dependences of a deployment are not reported on failure
In-Reply-To: <260387773.31474.1309494639012.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <949079204.32090.1309522704351.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved AS7-1162.
---------------------------------

      Assignee: Stuart Douglas
    Resolution: Done


> The missing dependences of a deployment are not reported on failure
> -------------------------------------------------------------------
>
>                 Key: AS7-1162
>                 URL: https://issues.jboss.org/browse/AS7-1162
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.CR1
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> When a deployment fails due to missing dependencies it does not report which dependencies are actually missing, making it very difficult to debug the underlying problem.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 08:18:24 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Fri, 1 Jul 2011 08:18:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1165) Improve error
 message(s) of deployment failures
In-Reply-To: <797335313.31854.1309516043727.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1968639348.32093.1309522704466.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved AS7-1165.
---------------------------------

         Assignee: Stuart Douglas
    Fix Version/s: 7.0.0.Final
                       (was: 7.1.0.Alpha1)
       Resolution: Done


> Improve error message(s) of deployment failures 
> ------------------------------------------------
>
>                 Key: AS7-1165
>                 URL: https://issues.jboss.org/browse/AS7-1165
>             Project: Application Server 7
>          Issue Type: Enhancement
>    Affects Versions: 7.0.0.CR1
>            Reporter: jaikiran pai
>            Assignee: Stuart Douglas
>             Fix For: 7.0.0.Final
>
>
> The error reporting in 7.0.0.CR1 for deployment failures due to missing dependencies is very complex and almost cannot be understood. Here are a couple of examples:
> http://community.jboss.org/message/612943#612943
> http://community.jboss.org/message/612555#612555
> This needs to be improved in later versions.
> I'm marking this as "Fix Version" 7.1.0.Alpha1 because I guess this isn't an easy change to incorporate in 7.0.0.Final. If it's possible to get this in for 7.0.0.Final then please change it accordingly.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 08:18:24 2011
From: jira-events at lists.jboss.org (Michal Linhard (JIRA))
Date: Fri, 1 Jul 2011 08:18:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1170) support configuration
 of number of virtual nodes
Message-ID: <230656898.32098.1309522704621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

support configuration of number of virtual nodes
------------------------------------------------

                 Key: AS7-1170
                 URL: https://issues.jboss.org/browse/AS7-1170
             Project: Application Server 7
          Issue Type: Feature Request
          Components: Clustering
    Affects Versions: 7.0.0.CR1
            Reporter: Michal Linhard
            Assignee: Paul Ferraro
            Priority: Critical


I recently played with consistent hash function implementation and produced various performance statistics.
It shows that number of virtual nodes (configuration parameter I98 in https://docspace.corp.redhat.com/docs/DOC-69249) has substantial effect on performance. (it makes distribution of data among nodes in the cluster much more even and thus avoids overstressing of one particular node, that would then hinder performance of the whole cluster)

If the next EDG6 Alpha build will take configuration from infinispan subsystem, we'll need to have this configurable, otherwise we won't be able to execute some very important performance comparisons.

it applies to the level of subsystem.cache-container.distributed-cache

so I propose addition of configuration parameter:
subsystem.cache-container.distributed-cache.numVirtualNodes that would have the same effect as I98 infinispan.configuration.clustering.hash.numVirtualNodes

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 08:18:24 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Fri, 1 Jul 2011 08:18:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1169) add test case
 deploying mysql driver and adding a Mysql's datasource
Message-ID: <163501901.32097.1309522704601.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

add test case deploying mysql driver and adding a Mysql's datasource
--------------------------------------------------------------------

                 Key: AS7-1169
                 URL: https://issues.jboss.org/browse/AS7-1169
             Project: Application Server 7
          Issue Type: Sub-task
            Reporter: Stefano Maestri
            Assignee: Stefano Maestri
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 08:22:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 1 Jul 2011 08:22:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1102) Create PKCS#11
 Compitable Cryptographic Services for Domain Management
In-Reply-To: <2030558315.16365.1308838704569.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <252203782.32103.1309522943642.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse reassigned AS7-1102:
-------------------------------------

    Assignee: Darran Lofthouse


> Create PKCS#11 Compitable Cryptographic Services for Domain Management
> ----------------------------------------------------------------------
>
>                 Key: AS7-1102
>                 URL: https://issues.jboss.org/browse/AS7-1102
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 7.1.0.Beta1
>
>
> Within domain management there are occasions where passwords need to be stored or keystores accessed either for encryption / decryption of password or to load the keys used for SSL exchanges.
> Commonly a password within code is used for password based encryption of other passwords, this obfuscates the password but does not over complicate the process of recovering the password, alternatively a local keystore can be used for the encryption but again everything is available on the local disk to recover the password.
> PKCS#11 will allow the cryptographic to be delegated to hardware which contains it's own protection against keys being made available.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 08:47:24 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Fri, 1 Jul 2011 08:47:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1164) add jdbc-driver :
 documentation incomplete or misleading
In-Reply-To: <2061849607.31723.1309511903626.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1802434184.32138.1309524444569.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefano Maestri commented on AS7-1164:
--------------------------------------

Not sure what you are trying to do. This operation can be used only with module loaded drivers. And in this case th driver-module-name is required.
For deployed ones you don't need this operation.

> add jdbc-driver : documentation incomplete or misleading
> --------------------------------------------------------
>
>                 Key: AS7-1164
>                 URL: https://issues.jboss.org/browse/AS7-1164
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.0.0.CR1
>            Reporter: Heiko Rupp
>            Assignee: Brian Stansberry
>
> I want to add a jdbc driver to a profile. The driver has been uploaded to /deployment
> [domain at localhost:9999 subsystem=datasources] pwd
> /profile=default/subsystem=datasources
> [domain at localhost:9999 subsystem=datasources] ./jdbc-driver=postgres9:add(driver-name=postgres9,deployment-name=postgresql-9.0-801.jdbc4.jar,driver-class-name=org.postgresql.Driver)
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "Operation handler failed: java.util.NoSuchElementException: No child 'driver-module-name' exists"},
>     "rolled-back" => true
> }
> Documentation says:
> [domain at localhost:9999 jdbc-driver=h2] :read-operation-description(name=add)                 
> {
>     "outcome" => "success",
>     "result" => {
>         "operation-name" => "add",
>         "description" => "Adds a new JDBC driver service",
>         "attributes" => {
>             "driver-name" => {
>                 "description" => "The symbolic name of this driver used to reference it in the register",
>                 "type" => STRING,
>                 "required" => true
>             },
>             "deployment-name" => {
>                 "description" => "The name of the deployment unit from which the driver was loaded, if it was loaded from a deployment",
>                 "type" => STRING
>             },
>             "driver-module-name" => {
>                 "description" => "The name of the module from which the driver was loaded, if it was loaded from the module path",
>                 "type" => STRING
>             },
>             "module-slot" => {
>                 "description" => "The slot of the module from which the driver was loaded, if it was loaded from the module path",
>                 "type" => STRING
>             },
>             "driver-class-name" => {
>                 "description" => "The fully qualified class name of the driver's implementation of java.sql.Driver",
>                 "type" => STRING
>             },
>             "driver-major-version" => {
>                 "description" => "The driver's major version number",
>                 "type" => INT
>             },
>             "driver-minor-version" => {
>                 "description" => "The driver's minor version number",
>                 "type" => INT
>             },
>             "jdbc-compliant" => {
>                 "description" => "Whether or not the driver is JDBC compliant",
>                 "type" => BOOLEAN
>             }
>         }
>     }
> }
> Here, only the driver-name is required.
> For driver-module-name it says "if loaded from module", which I read as "optional".
> Obviously from above error message, this is not optional

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 08:54:26 2011
From: jira-events at lists.jboss.org (Marek Novotny (JIRA))
Date: Fri, 1 Jul 2011 08:54:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1165) Improve error
 message(s) of deployment failures
In-Reply-To: <797335313.31854.1309516043727.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1947510657.32222.1309524866939.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Marek Novotny commented on AS7-1165:
------------------------------------

I have tried Stuart's fix (AS7-1162) and it works for me to be clear what is wrong with deployment dependencies.

> Improve error message(s) of deployment failures 
> ------------------------------------------------
>
>                 Key: AS7-1165
>                 URL: https://issues.jboss.org/browse/AS7-1165
>             Project: Application Server 7
>          Issue Type: Enhancement
>    Affects Versions: 7.0.0.CR1
>            Reporter: jaikiran pai
>            Assignee: Stuart Douglas
>             Fix For: 7.0.0.Final
>
>
> The error reporting in 7.0.0.CR1 for deployment failures due to missing dependencies is very complex and almost cannot be understood. Here are a couple of examples:
> http://community.jboss.org/message/612943#612943
> http://community.jboss.org/message/612555#612555
> This needs to be improved in later versions.
> I'm marking this as "Fix Version" 7.1.0.Alpha1 because I guess this isn't an easy change to incorporate in 7.0.0.Final. If it's possible to get this in for 7.0.0.Final then please change it accordingly.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 09:08:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 1 Jul 2011 09:08:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1171) datasource names that
 start with java:jdbc/ do not work
Message-ID: <2124232099.32265.1309525703692.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

datasource names that start with java:jdbc/ do not work
-------------------------------------------------------

                 Key: AS7-1171
                 URL: https://issues.jboss.org/browse/AS7-1171
             Project: Application Server 7
          Issue Type: Bug
    Affects Versions: 7.0.0.CR1
            Reporter: Scott Marlow


Using a datasource name like "java:jdbc/eFpDataSource" in a persistence.xml doesn't seem to work.  We seem to start to deploy the datasource but cannot resolve the service lookup.

Deploying an application that contains a persistence unit reference to the above datasource (see forum post for efp.ear zip), leads to the following server.log output:

07:20:11,374 DEBUG [org.jboss.as.connector.deployer.dsdeployer] (MSC service thread 1-1) Adding datasource: java:/java:jdbc/eFpDataSource

07:20:11,378 TRACE [org.jboss.as.naming.service.BinderService] (MSC service thread 1-2) Bound resource jdbc/eFpDataSource into naming store org.jboss.as.naming.InMemoryNamingStore at 65499154

   New missing/unsatisfied dependencies:
      service jboss.naming.context.java.java:jdbc/eFpDataSource (missing)


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 09:08:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 1 Jul 2011 09:08:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1171) datasource names that
 start with java:jdbc/ do not work
In-Reply-To: <2124232099.32265.1309525703692.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <545028273.32267.1309525703783.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow updated AS7-1171:
------------------------------

        Component/s: JCA
    Forum Reference: http://community.jboss.org/message/612948  (was: http://community.jboss.org/message/612948)


> datasource names that start with java:jdbc/ do not work
> -------------------------------------------------------
>
>                 Key: AS7-1171
>                 URL: https://issues.jboss.org/browse/AS7-1171
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 7.0.0.CR1
>            Reporter: Scott Marlow
>
> Using a datasource name like "java:jdbc/eFpDataSource" in a persistence.xml doesn't seem to work.  We seem to start to deploy the datasource but cannot resolve the service lookup.
> Deploying an application that contains a persistence unit reference to the above datasource (see forum post for efp.ear zip), leads to the following server.log output:
> 07:20:11,374 DEBUG [org.jboss.as.connector.deployer.dsdeployer] (MSC service thread 1-1) Adding datasource: java:/java:jdbc/eFpDataSource
> 07:20:11,378 TRACE [org.jboss.as.naming.service.BinderService] (MSC service thread 1-2) Bound resource jdbc/eFpDataSource into naming store org.jboss.as.naming.InMemoryNamingStore at 65499154
>    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.java:jdbc/eFpDataSource (missing)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 09:12:24 2011
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 1 Jul 2011 09:12:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1102) Create PKCS#11
 Compitable Cryptographic Services for Domain Management
In-Reply-To: <2030558315.16365.1308838704569.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1015279891.32277.1309525944400.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Anil Saldhana commented on AS7-1102:
------------------------------------

We are planning to design a generic solution for the AS via PicketBox. This task should utilize that rather than create its own.

> Create PKCS#11 Compitable Cryptographic Services for Domain Management
> ----------------------------------------------------------------------
>
>                 Key: AS7-1102
>                 URL: https://issues.jboss.org/browse/AS7-1102
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 7.1.0.Beta1
>
>
> Within domain management there are occasions where passwords need to be stored or keystores accessed either for encryption / decryption of password or to load the keys used for SSL exchanges.
> Commonly a password within code is used for password based encryption of other passwords, this obfuscates the password but does not over complicate the process of recovering the password, alternatively a local keystore can be used for the encryption but again everything is available on the local disk to recover the password.
> PKCS#11 will allow the cryptographic to be delegated to hardware which contains it's own protection against keys being made available.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 09:23:23 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Fri, 1 Jul 2011 09:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1164) add jdbc-driver :
 documentation incomplete or misleading
In-Reply-To: <2061849607.31723.1309511903626.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1125802078.32286.1309526603809.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Rupp commented on AS7-1164:
---------------------------------

I am trying this:
./jdbc-driver=postgres9:add(driver-name=postgres9,deployment-name=postgresql-9.0-801.jdbc4.jar,driver-class-name=org.postgresql.Driver)

And as a result I get an error that the "module-name" is missing. Which you say is not needed anyway. So either validation of parameters of :add is wrong or the documentation of :add

> add jdbc-driver : documentation incomplete or misleading
> --------------------------------------------------------
>
>                 Key: AS7-1164
>                 URL: https://issues.jboss.org/browse/AS7-1164
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.0.0.CR1
>            Reporter: Heiko Rupp
>            Assignee: Brian Stansberry
>
> I want to add a jdbc driver to a profile. The driver has been uploaded to /deployment
> [domain at localhost:9999 subsystem=datasources] pwd
> /profile=default/subsystem=datasources
> [domain at localhost:9999 subsystem=datasources] ./jdbc-driver=postgres9:add(driver-name=postgres9,deployment-name=postgresql-9.0-801.jdbc4.jar,driver-class-name=org.postgresql.Driver)
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "Operation handler failed: java.util.NoSuchElementException: No child 'driver-module-name' exists"},
>     "rolled-back" => true
> }
> Documentation says:
> [domain at localhost:9999 jdbc-driver=h2] :read-operation-description(name=add)                 
> {
>     "outcome" => "success",
>     "result" => {
>         "operation-name" => "add",
>         "description" => "Adds a new JDBC driver service",
>         "attributes" => {
>             "driver-name" => {
>                 "description" => "The symbolic name of this driver used to reference it in the register",
>                 "type" => STRING,
>                 "required" => true
>             },
>             "deployment-name" => {
>                 "description" => "The name of the deployment unit from which the driver was loaded, if it was loaded from a deployment",
>                 "type" => STRING
>             },
>             "driver-module-name" => {
>                 "description" => "The name of the module from which the driver was loaded, if it was loaded from the module path",
>                 "type" => STRING
>             },
>             "module-slot" => {
>                 "description" => "The slot of the module from which the driver was loaded, if it was loaded from the module path",
>                 "type" => STRING
>             },
>             "driver-class-name" => {
>                 "description" => "The fully qualified class name of the driver's implementation of java.sql.Driver",
>                 "type" => STRING
>             },
>             "driver-major-version" => {
>                 "description" => "The driver's major version number",
>                 "type" => INT
>             },
>             "driver-minor-version" => {
>                 "description" => "The driver's minor version number",
>                 "type" => INT
>             },
>             "jdbc-compliant" => {
>                 "description" => "Whether or not the driver is JDBC compliant",
>                 "type" => BOOLEAN
>             }
>         }
>     }
> }
> Here, only the driver-name is required.
> For driver-module-name it says "if loaded from module", which I read as "optional".
> Obviously from above error message, this is not optional

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 09:31:23 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Fri, 1 Jul 2011 09:31:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1164) add jdbc-driver :
 documentation incomplete or misleading
In-Reply-To: <2061849607.31723.1309511903626.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1965167856.32316.1309527083929.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefano Maestri commented on AS7-1164:
--------------------------------------

No I'm saying it's needed. You are adding a driver from jar loaded as module.
If you are deploying the driver you should use something like that

deploy /home/maeste/Desktop/postgresql-9.0-801.jdbc4.ja


> add jdbc-driver : documentation incomplete or misleading
> --------------------------------------------------------
>
>                 Key: AS7-1164
>                 URL: https://issues.jboss.org/browse/AS7-1164
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.0.0.CR1
>            Reporter: Heiko Rupp
>            Assignee: Brian Stansberry
>
> I want to add a jdbc driver to a profile. The driver has been uploaded to /deployment
> [domain at localhost:9999 subsystem=datasources] pwd
> /profile=default/subsystem=datasources
> [domain at localhost:9999 subsystem=datasources] ./jdbc-driver=postgres9:add(driver-name=postgres9,deployment-name=postgresql-9.0-801.jdbc4.jar,driver-class-name=org.postgresql.Driver)
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "Operation handler failed: java.util.NoSuchElementException: No child 'driver-module-name' exists"},
>     "rolled-back" => true
> }
> Documentation says:
> [domain at localhost:9999 jdbc-driver=h2] :read-operation-description(name=add)                 
> {
>     "outcome" => "success",
>     "result" => {
>         "operation-name" => "add",
>         "description" => "Adds a new JDBC driver service",
>         "attributes" => {
>             "driver-name" => {
>                 "description" => "The symbolic name of this driver used to reference it in the register",
>                 "type" => STRING,
>                 "required" => true
>             },
>             "deployment-name" => {
>                 "description" => "The name of the deployment unit from which the driver was loaded, if it was loaded from a deployment",
>                 "type" => STRING
>             },
>             "driver-module-name" => {
>                 "description" => "The name of the module from which the driver was loaded, if it was loaded from the module path",
>                 "type" => STRING
>             },
>             "module-slot" => {
>                 "description" => "The slot of the module from which the driver was loaded, if it was loaded from the module path",
>                 "type" => STRING
>             },
>             "driver-class-name" => {
>                 "description" => "The fully qualified class name of the driver's implementation of java.sql.Driver",
>                 "type" => STRING
>             },
>             "driver-major-version" => {
>                 "description" => "The driver's major version number",
>                 "type" => INT
>             },
>             "driver-minor-version" => {
>                 "description" => "The driver's minor version number",
>                 "type" => INT
>             },
>             "jdbc-compliant" => {
>                 "description" => "Whether or not the driver is JDBC compliant",
>                 "type" => BOOLEAN
>             }
>         }
>     }
> }
> Here, only the driver-name is required.
> For driver-module-name it says "if loaded from module", which I read as "optional".
> Obviously from above error message, this is not optional

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 09:48:23 2011
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 1 Jul 2011 09:48:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-687) Add proxy for
 jfrog plugin releases repo
Message-ID: <646159953.32353.1309528103673.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Add proxy for jfrog plugin releases repo
----------------------------------------

                 Key: JBBUILD-687
                 URL: https://issues.jboss.org/browse/JBBUILD-687
             Project: JBoss Build System
          Issue Type: Task
          Components: Artifact Repositories
            Reporter: Paul Gier
            Assignee: Paul Gier
             Fix For: Build Support 2011


Hardy and Sanne requested to add a proxy repo for the jfrog plugin releases repository.  This repository contains org.jfrog.maven.annomojo:maven-plugin-tools-anno

http://repo.jfrog.org/artifactory/plugins-releases-local

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 09:50:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 1 Jul 2011 09:50:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1171) datasource names that
 start with java:jdbc/ do not work
In-Reply-To: <2124232099.32265.1309525703692.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1833155919.32359.1309528223890.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow updated AS7-1171:
------------------------------

           Assignee: John Bailey
      Fix Version/s: 7.0.0.Final
    Forum Reference: http://community.jboss.org/message/612948  (was: http://community.jboss.org/message/612948)


> datasource names that start with java:jdbc/ do not work
> -------------------------------------------------------
>
>                 Key: AS7-1171
>                 URL: https://issues.jboss.org/browse/AS7-1171
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 7.0.0.CR1
>            Reporter: Scott Marlow
>            Assignee: John Bailey
>             Fix For: 7.0.0.Final
>
>
> Using a datasource name like "java:jdbc/eFpDataSource" in a persistence.xml doesn't seem to work.  We seem to start to deploy the datasource but cannot resolve the service lookup.
> Deploying an application that contains a persistence unit reference to the above datasource (see forum post for efp.ear zip), leads to the following server.log output:
> 07:20:11,374 DEBUG [org.jboss.as.connector.deployer.dsdeployer] (MSC service thread 1-1) Adding datasource: java:/java:jdbc/eFpDataSource
> 07:20:11,378 TRACE [org.jboss.as.naming.service.BinderService] (MSC service thread 1-2) Bound resource jdbc/eFpDataSource into naming store org.jboss.as.naming.InMemoryNamingStore at 65499154
>    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.java:jdbc/eFpDataSource (missing)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 09:52:23 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Fri, 1 Jul 2011 09:52:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1164) add jdbc-driver :
 documentation incomplete or misleading
In-Reply-To: <2061849607.31723.1309511903626.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1698388645.32365.1309528343827.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Rupp commented on AS7-1164:
---------------------------------

I did upload that driver first to /deployment as a domain-deployment and want deploy that later into a profile. I did not define a module or such.
And I am trying to do that via the JSON api, but for illustration purposes I am using the "raw cli commands"

> add jdbc-driver : documentation incomplete or misleading
> --------------------------------------------------------
>
>                 Key: AS7-1164
>                 URL: https://issues.jboss.org/browse/AS7-1164
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.0.0.CR1
>            Reporter: Heiko Rupp
>            Assignee: Brian Stansberry
>
> I want to add a jdbc driver to a profile. The driver has been uploaded to /deployment
> [domain at localhost:9999 subsystem=datasources] pwd
> /profile=default/subsystem=datasources
> [domain at localhost:9999 subsystem=datasources] ./jdbc-driver=postgres9:add(driver-name=postgres9,deployment-name=postgresql-9.0-801.jdbc4.jar,driver-class-name=org.postgresql.Driver)
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "Operation handler failed: java.util.NoSuchElementException: No child 'driver-module-name' exists"},
>     "rolled-back" => true
> }
> Documentation says:
> [domain at localhost:9999 jdbc-driver=h2] :read-operation-description(name=add)                 
> {
>     "outcome" => "success",
>     "result" => {
>         "operation-name" => "add",
>         "description" => "Adds a new JDBC driver service",
>         "attributes" => {
>             "driver-name" => {
>                 "description" => "The symbolic name of this driver used to reference it in the register",
>                 "type" => STRING,
>                 "required" => true
>             },
>             "deployment-name" => {
>                 "description" => "The name of the deployment unit from which the driver was loaded, if it was loaded from a deployment",
>                 "type" => STRING
>             },
>             "driver-module-name" => {
>                 "description" => "The name of the module from which the driver was loaded, if it was loaded from the module path",
>                 "type" => STRING
>             },
>             "module-slot" => {
>                 "description" => "The slot of the module from which the driver was loaded, if it was loaded from the module path",
>                 "type" => STRING
>             },
>             "driver-class-name" => {
>                 "description" => "The fully qualified class name of the driver's implementation of java.sql.Driver",
>                 "type" => STRING
>             },
>             "driver-major-version" => {
>                 "description" => "The driver's major version number",
>                 "type" => INT
>             },
>             "driver-minor-version" => {
>                 "description" => "The driver's minor version number",
>                 "type" => INT
>             },
>             "jdbc-compliant" => {
>                 "description" => "Whether or not the driver is JDBC compliant",
>                 "type" => BOOLEAN
>             }
>         }
>     }
> }
> Here, only the driver-name is required.
> For driver-module-name it says "if loaded from module", which I read as "optional".
> Obviously from above error message, this is not optional

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 10:18:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 1 Jul 2011 10:18:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1171) datasource names
 that start with java:jdbc/ do not work
In-Reply-To: <2124232099.32265.1309525703692.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1073311247.32404.1309529903738.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on AS7-1171:
-----------------------------------

John, if you come up with a fix, please post a link to the commit here and I'll do some additional testing on hudson with your change.

The test case from the above forum link is http://community.jboss.org/servlet/JiveServlet/download/612940-35910/efp.zip (contains efp.ear).

Before deploying the efp.ear, the exampleds in standalone.xml, should be changed to "java:jdbc/eFpDataSource".

> datasource names that start with java:jdbc/ do not work
> -------------------------------------------------------
>
>                 Key: AS7-1171
>                 URL: https://issues.jboss.org/browse/AS7-1171
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 7.0.0.CR1
>            Reporter: Scott Marlow
>            Assignee: John Bailey
>             Fix For: 7.0.0.Final
>
>
> Using a datasource name like "java:jdbc/eFpDataSource" in a persistence.xml doesn't seem to work.  We seem to start to deploy the datasource but cannot resolve the service lookup.
> Deploying an application that contains a persistence unit reference to the above datasource (see forum post for efp.ear zip), leads to the following server.log output:
> 07:20:11,374 DEBUG [org.jboss.as.connector.deployer.dsdeployer] (MSC service thread 1-1) Adding datasource: java:/java:jdbc/eFpDataSource
> 07:20:11,378 TRACE [org.jboss.as.naming.service.BinderService] (MSC service thread 1-2) Bound resource jdbc/eFpDataSource into naming store org.jboss.as.naming.InMemoryNamingStore at 65499154
>    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.java:jdbc/eFpDataSource (missing)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 10:39:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Fri, 1 Jul 2011 10:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1170) support configuration
 of number of virtual nodes
In-Reply-To: <230656898.32098.1309522704621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <664707315.32438.1309531163856.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro updated AS7-1170:
------------------------------

    Fix Version/s: 7.0.0.Final


> support configuration of number of virtual nodes
> ------------------------------------------------
>
>                 Key: AS7-1170
>                 URL: https://issues.jboss.org/browse/AS7-1170
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 7.0.0.CR1
>            Reporter: Michal Linhard
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 7.0.0.Final
>
>
> I recently played with consistent hash function implementation and produced various performance statistics.
> It shows that number of virtual nodes (configuration parameter I98 in https://docspace.corp.redhat.com/docs/DOC-69249) has substantial effect on performance. (it makes distribution of data among nodes in the cluster much more even and thus avoids overstressing of one particular node, that would then hinder performance of the whole cluster)
> If the next EDG6 Alpha build will take configuration from infinispan subsystem, we'll need to have this configurable, otherwise we won't be able to execute some very important performance comparisons.
> it applies to the level of subsystem.cache-container.distributed-cache
> so I propose addition of configuration parameter:
> subsystem.cache-container.distributed-cache.numVirtualNodes that would have the same effect as I98 infinispan.configuration.clustering.hash.numVirtualNodes

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 11:56:23 2011
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 1 Jul 2011 11:56:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-687) Add proxy for jfrog
 plugin releases repo
In-Reply-To: <646159953.32353.1309528103673.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <700114526.32507.1309535783642.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Gier closed JBBUILD-687.
-----------------------------

    Resolution: Done


The repo has been added.

> Add proxy for jfrog plugin releases repo
> ----------------------------------------
>
>                 Key: JBBUILD-687
>                 URL: https://issues.jboss.org/browse/JBBUILD-687
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Artifact Repositories
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>             Fix For: Build Support 2011
>
>
> Hardy and Sanne requested to add a proxy repo for the jfrog plugin releases repository.  This repository contains org.jfrog.maven.annomojo:maven-plugin-tools-anno
> http://repo.jfrog.org/artifactory/plugins-releases-local

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 12:39:23 2011
From: jira-events at lists.jboss.org (Alexandre Gattiker (JIRA))
Date: Fri, 1 Jul 2011 12:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1172) JNDI
Message-ID: <553584792.32548.1309538363672.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

JNDI 
-----

                 Key: AS7-1172
                 URL: https://issues.jboss.org/browse/AS7-1172
             Project: Application Server 7
          Issue Type: Bug
          Components: Naming
    Affects Versions: 7.0.0.CR1
            Reporter: Alexandre Gattiker


If a JMS destination is created with a JNDI name starting with "/jms/", the JNDI View issues an error message. The destination appears to be up and running fine though.

<h1>java: Namespace</h1>
<pre>
  +- topic (class: javax.naming.Context)
  |   +- test (class: org.jboss.as.naming.context.ModularReference)
  +- app (class: javax.naming.Reference)
  +- module (class: javax.naming.Reference)
  +- comp (class: javax.naming.Reference)
  +- queue (class: javax.naming.Context)
  |   +- test (class: org.jboss.as.naming.context.ModularReference)
  +- jms (class: javax.naming.Context)
Failed to lookup: jms, errmsg=Name 'jms' not found in context ''
  +- global (class: javax.naming.Reference)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 21:16:23 2011
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 1 Jul 2011 21:16:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-3114) regression: set
 test operator "in" broken
In-Reply-To: <1472273612.29993.1309443143682.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1591218001.32722.1309569383886.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Edson Tirelli resolved JBRULES-3114.
------------------------------------

         Assignee: Edson Tirelli  (was: Mark Proctor)
    Fix Version/s: 5.3.0.Beta1
                       (was: FUTURE)
       Resolution: Done


Fixed. Thanks for reporting.

> regression: set test operator "in" broken 
> ------------------------------------------
>
>                 Key: JBRULES-3114
>                 URL: https://issues.jboss.org/browse/JBRULES-3114
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler (expert)
>    Affects Versions: 5.2.0.Final
>            Reporter: Wolfgang Laun
>            Assignee: Edson Tirelli
>            Priority: Blocker
>             Fix For: 5.3.0.Beta1
>
>
> This simple DRL runs into a NPE
> rule a
> when
> then
>     insert( Integer.class );
> end
> rule xxx
> when
>     $t: Class( $name: name not in ( "java.lang.Integer", "Bar", "Blech" ) )
> then
>     System.out.println( "odd name: " + $t.getName() );
> end
> Caused by: java.lang.NullPointerException
> 	at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:104)
> 	at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:291)
> If the "not" is removed, another strange error is thrown, claiming that 'name' cannot be accessed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 21:18:23 2011
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 1 Jul 2011 21:18:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-3114) regression: set
 test operator "in" broken
In-Reply-To: <1472273612.29993.1309443143682.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1579548591.32726.1309569503685.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Edson Tirelli updated JBRULES-3114:
-----------------------------------

    Fix Version/s: 5.2.1.Final


> regression: set test operator "in" broken 
> ------------------------------------------
>
>                 Key: JBRULES-3114
>                 URL: https://issues.jboss.org/browse/JBRULES-3114
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler (expert)
>    Affects Versions: 5.2.0.Final
>            Reporter: Wolfgang Laun
>            Assignee: Edson Tirelli
>            Priority: Blocker
>             Fix For: 5.2.1.Final, 5.3.0.Beta1
>
>
> This simple DRL runs into a NPE
> rule a
> when
> then
>     insert( Integer.class );
> end
> rule xxx
> when
>     $t: Class( $name: name not in ( "java.lang.Integer", "Bar", "Blech" ) )
> then
>     System.out.println( "odd name: " + $t.getName() );
> end
> Caused by: java.lang.NullPointerException
> 	at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:104)
> 	at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:291)
> If the "not" is removed, another strange error is thrown, claiming that 'name' cannot be accessed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  1 21:20:23 2011
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 1 Jul 2011 21:20:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-3114) regression: set
 test operator "in" broken
In-Reply-To: <1472273612.29993.1309443143682.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <227160303.32730.1309569623667.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Edson Tirelli closed JBRULES-3114.
----------------------------------



> regression: set test operator "in" broken 
> ------------------------------------------
>
>                 Key: JBRULES-3114
>                 URL: https://issues.jboss.org/browse/JBRULES-3114
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler (expert)
>    Affects Versions: 5.2.0.Final
>            Reporter: Wolfgang Laun
>            Assignee: Edson Tirelli
>            Priority: Blocker
>             Fix For: 5.2.1.Final, 5.3.0.Beta1
>
>
> This simple DRL runs into a NPE
> rule a
> when
> then
>     insert( Integer.class );
> end
> rule xxx
> when
>     $t: Class( $name: name not in ( "java.lang.Integer", "Bar", "Blech" ) )
> then
>     System.out.println( "odd name: " + $t.getName() );
> end
> Caused by: java.lang.NullPointerException
> 	at org.drools.base.mvel.MVELPredicateExpression.evaluate(MVELPredicateExpression.java:104)
> 	at org.drools.rule.PredicateConstraint.isAllowed(PredicateConstraint.java:291)
> If the "not" is removed, another strange error is thrown, claiming that 'name' cannot be accessed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul  2 00:31:24 2011
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Sat, 2 Jul 2011 00:31:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1151) Error while
 registering Oracle JDBC Diagnosability MBean
In-Reply-To: <756188351.29161.1309420043598.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1691680252.32741.1309581084079.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

SBS JIRA Integration updated AS7-1151:
--------------------------------------

    Forum Reference: http://community.jboss.org/message/612942#612942


> Error while registering Oracle JDBC Diagnosability MBean
> --------------------------------------------------------
>
>                 Key: AS7-1151
>                 URL: https://issues.jboss.org/browse/AS7-1151
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMX
>    Affects Versions: 7.0.0.CR1
>            Reporter: Nicklas Karlsson
>            Assignee: Stefano Maestri
>
> Deploying the Oracle 11.1 driver jdbc-driver-11.1.0.6.0.jar through the admin console gives a 
> 10:42:15,938 SEVERE [oracle.jdbc] (MSC service thread 1-7) Error while registering Oracle JDBC Diagnosability MBean.: java.lang.NullPointerException
> 	at oracle.jdbc.driver.OracleDriver.registerMBeans(OracleDriver.java:301)
> 	at oracle.jdbc.driver.OracleDriver$1.run(OracleDriver.java:213)
> 	at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_23]
> 	at oracle.jdbc.driver.OracleDriver.<clinit>(OracleDriver.java:209)
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [:1.6.0_23]
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) [:1.6.0_23]
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) [:1.6.0_23]
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:513) [:1.6.0_23]
> 	at org.jboss.as.connector.deployers.processors.DriverProcessor.deploy(DriverProcessor.java:66)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
> 	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_23]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_23]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_23]
> the driver looks registered/enabled, though, this is just an error from the diagnose bean

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul  2 11:08:23 2011
From: jira-events at lists.jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=)
Date: Sat, 2 Jul 2011 11:08:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBWEB-205) Invalid async
 context for servlet: Atmosphere Async Servlet on JBoss Web
Message-ID: <1369266963.32802.1309619303616.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Invalid async context for servlet: Atmosphere Async  Servlet on JBoss Web
-------------------------------------------------------------------------

                 Key: JBWEB-205
                 URL: https://issues.jboss.org/browse/JBWEB-205
             Project: JBoss Web
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: Firefox 4.0.1 / Chromium 12 
AS 6.0.0.Final / 6.1.0-SNAPSHOT / AS 7.0.0.CR1 
Atmosphere 0.7.1/0.7.2 
            Reporter: Luk?? Fry?
            Assignee: Remy Maucherat


Source of sample for reproduction:
https://github.com/lfryc/push-jms/commit/9cee160570e049ca4783e1fcbdac25ffef1b10b7

{code}
16:08:28,467 ERROR [org.apache.catalina.connector.CoyoteAdapter] (http-localhost-127.0.0.1-8080-7) An exception or error occurred in the container during the request processing: java.lang.IllegalStateException: Invalid async context for servlet AutoRegisteredPushServlet
	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:643) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:402) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:183) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:246) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:128) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:265) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
	at org.apache.coyote.http11.Http11Processor.event(Http11Processor.java:757) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.event(Http11Protocol.java:615) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:938) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
	at java.lang.Thread.run(Thread.java:636) [:1.6.0_20]
{code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Sat Jul  2 11:10:23 2011
From: jira-events at lists.jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Fry=C4=8D_=28JIRA=29?=)
Date: Sat, 2 Jul 2011 11:10:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-205) Invalid async
 context for servlet: Atmosphere Async Servlet on JBoss Web
In-Reply-To: <1369266963.32802.1309619303616.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1318582227.32805.1309619423644.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Luk?? Fry? updated JBWEB-205:
-----------------------------

    Attachment: push-jms.war


Attaching WAR for reproduction.

> Invalid async context for servlet: Atmosphere Async  Servlet on JBoss Web
> -------------------------------------------------------------------------
>
>                 Key: JBWEB-205
>                 URL: https://issues.jboss.org/browse/JBWEB-205
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Firefox 4.0.1 / Chromium 12 
> AS 6.0.0.Final / 6.1.0-SNAPSHOT / AS 7.0.0.CR1 
> Atmosphere 0.7.1/0.7.2 
>            Reporter: Luk?? Fry?
>            Assignee: Remy Maucherat
>         Attachments: push-jms.war
>
>
> Source of sample for reproduction:
> https://github.com/lfryc/push-jms/commit/9cee160570e049ca4783e1fcbdac25ffef1b10b7
> {code}
> 16:08:28,467 ERROR [org.apache.catalina.connector.CoyoteAdapter] (http-localhost-127.0.0.1-8080-7) An exception or error occurred in the container during the request processing: java.lang.IllegalStateException: Invalid async context for servlet AutoRegisteredPushServlet
> 	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:643) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:402) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:183) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:246) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:128) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:265) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11Processor.event(Http11Processor.java:757) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.event(Http11Protocol.java:615) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:938) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at java.lang.Thread.run(Thread.java:636) [:1.6.0_20]
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Sat Jul  2 11:20:24 2011
From: jira-events at lists.jboss.org (Savas Ali Tokmen (JIRA))
Date: Sat, 2 Jul 2011 11:20:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-682)
 http://repository.jboss.org/maven2/ serving HTTP 403 to hosts outside
 RedHat VPN
In-Reply-To: <1378297995.38124.1306874040969.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <560122398.32814.1309620024015.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Savas Ali Tokmen commented on JBBUILD-682:
------------------------------------------

Hello

Even if JBoss does not want to reenable the repository, can JBoss please at least comply with usual standards and return an error 404 instead of an error 401?

Thank you

> http://repository.jboss.org/maven2/ serving HTTP 403 to hosts outside RedHat VPN
> --------------------------------------------------------------------------------
>
>                 Key: JBBUILD-682
>                 URL: https://issues.jboss.org/browse/JBBUILD-682
>             Project: JBoss Build System
>          Issue Type: Bug
>            Reporter: Marek Schmidt
>            Assignee: Paul Gier
>            Priority: Critical
>             Fix For: Build Support 2011
>
>
> The legacy maven repository http://repository.jboss.org/maven2/ is serving HTTP 403 to hosts outside RedHat VPN, causing lots of builds to fail.
> e.g. http://community.jboss.org/message/606819?tstart=0 with error:
> Access denied to: http://repository.jboss.org/maven2/trove/trove/2.1.1/trove-2.1.1.pom

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul  2 11:22:23 2011
From: jira-events at lists.jboss.org (Savas Ali Tokmen (JIRA))
Date: Sat, 2 Jul 2011 11:22:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (JBBUILD-682)
 http://repository.jboss.org/maven2/ serving HTTP 403 to hosts outside
 RedHat VPN
In-Reply-To: <1378297995.38124.1306874040969.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1397538961.32817.1309620143660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Savas Ali Tokmen edited comment on JBBUILD-682 at 7/2/11 11:21 AM:
-------------------------------------------------------------------

Hello

Even if JBoss does not want to reenable the repository, can JBoss please at least comply with usual standards and return an error 404 instead of an error 403?

Maven actually thinks that something is wrong with the project when there is an error 403. Returning an error 404 will at least help builds not fail.

Thank you

      was (Author: alitokmen):
    Hello

Even if JBoss does not want to reenable the repository, can JBoss please at least comply with usual standards and return an error 404 instead of an error 401?

Thank you
  
> http://repository.jboss.org/maven2/ serving HTTP 403 to hosts outside RedHat VPN
> --------------------------------------------------------------------------------
>
>                 Key: JBBUILD-682
>                 URL: https://issues.jboss.org/browse/JBBUILD-682
>             Project: JBoss Build System
>          Issue Type: Bug
>            Reporter: Marek Schmidt
>            Assignee: Paul Gier
>            Priority: Critical
>             Fix For: Build Support 2011
>
>
> The legacy maven repository http://repository.jboss.org/maven2/ is serving HTTP 403 to hosts outside RedHat VPN, causing lots of builds to fail.
> e.g. http://community.jboss.org/message/606819?tstart=0 with error:
> Access denied to: http://repository.jboss.org/maven2/trove/trove/2.1.1/trove-2.1.1.pom

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul  2 12:04:23 2011
From: jira-events at lists.jboss.org (Marius Bogoevici (JIRA))
Date: Sat, 2 Jul 2011 12:04:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1173) 'transformers'
 element not declared in jboss-deployment-structure-1_0.xsd
Message-ID: <811986275.32827.1309622663611.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

'transformers' element not declared in jboss-deployment-structure-1_0.xsd
-------------------------------------------------------------------------

                 Key: AS7-1173
                 URL: https://issues.jboss.org/browse/AS7-1173
             Project: Application Server 7
          Issue Type: Bug
            Reporter: Marius Bogoevici
            Assignee: Marius Bogoevici


The 'transformers' element is not declared as part of the 'deploymentType' type.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul  2 12:06:23 2011
From: jira-events at lists.jboss.org (Marius Bogoevici (JIRA))
Date: Sat, 2 Jul 2011 12:06:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1173) 'transformers'
 element not declared in jboss-deployment-structure-1_0.xsd
In-Reply-To: <811986275.32827.1309622663611.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <699920669.32830.1309622783653.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Marius Bogoevici updated AS7-1173:
----------------------------------

        Fix Version/s: 7.0.0.Final
    Affects Version/s: 7.0.0.CR1


> 'transformers' element not declared in jboss-deployment-structure-1_0.xsd
> -------------------------------------------------------------------------
>
>                 Key: AS7-1173
>                 URL: https://issues.jboss.org/browse/AS7-1173
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.CR1
>            Reporter: Marius Bogoevici
>            Assignee: Marius Bogoevici
>             Fix For: 7.0.0.Final
>
>
> The 'transformers' element is not declared as part of the 'deploymentType' type.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul  2 12:33:23 2011
From: jira-events at lists.jboss.org (Aslak Knutsen (JIRA))
Date: Sat, 2 Jul 2011 12:33:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1174) Arquillian Containers
 can not be used as a general purpose Container Adapter due to a internal
 deployment registry
Message-ID: <1725209106.32833.1309624403620.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Arquillian Containers can not be used as a general purpose Container Adapter due to a internal deployment registry
------------------------------------------------------------------------------------------------------------------

                 Key: AS7-1174
                 URL: https://issues.jboss.org/browse/AS7-1174
             Project: Application Server 7
          Issue Type: Bug
          Components: Test Suite
    Affects Versions: 7.0.0.CR1
            Reporter: Aslak Knutsen


The CommonDeployableContainer keeps a registry of deployed deployments and their unique id in memory between deploy and undeploy. So unless the deployment you try to undeploy was deployed using the same instance of the Container it can't be undeployed. 

This cause problems for use of the Container in e.g. SeamForge or MavenPlugin, where the JVM is taken up and down between deploy/undeploy operations.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul  2 12:35:23 2011
From: jira-events at lists.jboss.org (Aslak Knutsen (JIRA))
Date: Sat, 2 Jul 2011 12:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1174) Arquillian Containers
 can not undeploy Archives not deployed using the same Container instance
In-Reply-To: <1725209106.32833.1309624403620.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <372206128.32836.1309624523696.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Aslak Knutsen updated AS7-1174:
-------------------------------

    Summary: Arquillian Containers can not undeploy Archives not deployed using the same Container instance  (was: Arquillian Containers can not be used as a general purpose Container Adapter due to a internal deployment registry)


> Arquillian Containers can not undeploy Archives not deployed using the same Container instance
> ----------------------------------------------------------------------------------------------
>
>                 Key: AS7-1174
>                 URL: https://issues.jboss.org/browse/AS7-1174
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 7.0.0.CR1
>            Reporter: Aslak Knutsen
>
> The CommonDeployableContainer keeps a registry of deployed deployments and their unique id in memory between deploy and undeploy. So unless the deployment you try to undeploy was deployed using the same instance of the Container it can't be undeployed. 
> This cause problems for use of the Container in e.g. SeamForge or MavenPlugin, where the JVM is taken up and down between deploy/undeploy operations.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul  2 14:29:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Sat, 2 Jul 2011 14:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1171) datasource names that
 start with java:jdbc/ do not work
In-Reply-To: <2124232099.32265.1309525703692.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1642780464.32843.1309631363814.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow updated AS7-1171:
------------------------------

    Forum Reference: http://community.jboss.org/message/612948, http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/thread.html#2879  (was: http://community.jboss.org/message/612948)


> datasource names that start with java:jdbc/ do not work
> -------------------------------------------------------
>
>                 Key: AS7-1171
>                 URL: https://issues.jboss.org/browse/AS7-1171
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 7.0.0.CR1
>            Reporter: Scott Marlow
>            Assignee: John Bailey
>             Fix For: 7.0.0.Final
>
>
> Using a datasource name like "java:jdbc/eFpDataSource" in a persistence.xml doesn't seem to work.  We seem to start to deploy the datasource but cannot resolve the service lookup.
> Deploying an application that contains a persistence unit reference to the above datasource (see forum post for efp.ear zip), leads to the following server.log output:
> 07:20:11,374 DEBUG [org.jboss.as.connector.deployer.dsdeployer] (MSC service thread 1-1) Adding datasource: java:/java:jdbc/eFpDataSource
> 07:20:11,378 TRACE [org.jboss.as.naming.service.BinderService] (MSC service thread 1-2) Bound resource jdbc/eFpDataSource into naming store org.jboss.as.naming.InMemoryNamingStore at 65499154
>    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.java:jdbc/eFpDataSource (missing)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul  2 14:39:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Sat, 2 Jul 2011 14:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1171) datasource names
 that start with java:jdbc/ do not work
In-Reply-To: <2124232099.32265.1309525703692.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <985907446.32848.1309631963848.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on AS7-1171:
-----------------------------------

>From the ML discussion thread (2nd forum reference link above), suggests that we should give an "invalid name error" when attempting to bind with name "java:jdbc/eFpDataSource" (same for lookup).


> datasource names that start with java:jdbc/ do not work
> -------------------------------------------------------
>
>                 Key: AS7-1171
>                 URL: https://issues.jboss.org/browse/AS7-1171
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 7.0.0.CR1
>            Reporter: Scott Marlow
>            Assignee: John Bailey
>             Fix For: 7.0.0.Final
>
>
> Using a datasource name like "java:jdbc/eFpDataSource" in a persistence.xml doesn't seem to work.  We seem to start to deploy the datasource but cannot resolve the service lookup.
> Deploying an application that contains a persistence unit reference to the above datasource (see forum post for efp.ear zip), leads to the following server.log output:
> 07:20:11,374 DEBUG [org.jboss.as.connector.deployer.dsdeployer] (MSC service thread 1-1) Adding datasource: java:/java:jdbc/eFpDataSource
> 07:20:11,378 TRACE [org.jboss.as.naming.service.BinderService] (MSC service thread 1-2) Bound resource jdbc/eFpDataSource into naming store org.jboss.as.naming.InMemoryNamingStore at 65499154
>    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.java:jdbc/eFpDataSource (missing)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul  2 16:20:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Sat, 2 Jul 2011 16:20:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1171) relative names that
 start with "java:XXX", XXX must be: "comp", "module", "app", "global",
 "jboss"
In-Reply-To: <2124232099.32265.1309525703692.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1655624492.32861.1309638023740.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow updated AS7-1171:
------------------------------

            Summary: relative names that start with "java:XXX", XXX must be: "comp", "module", "app", "global","jboss"  (was: datasource names that start with java:jdbc/ do not work)
        Description: 
Using a datasource name like "java:jdbc/eFpDataSource" in a persistence.xml doesn't seem to work.  We seem to start to deploy the datasource but cannot resolve the service lookup.

Deploying an application that contains a persistence unit reference to the above datasource (see forum post for efp.ear zip), leads to the following server.log output:

07:20:11,374 DEBUG [org.jboss.as.connector.deployer.dsdeployer] (MSC service thread 1-1) Adding datasource: java:/java:jdbc/eFpDataSource

07:20:11,378 TRACE [org.jboss.as.naming.service.BinderService] (MSC service thread 1-2) Bound resource jdbc/eFpDataSource into naming store org.jboss.as.naming.InMemoryNamingStore at 65499154

And the application (includes persistence.xml reference to EfpDataSource) fails to deploy, with the following:
   New missing/unsatisfied dependencies:
      service jboss.naming.context.java.java:jdbc/eFpDataSource (missing)

Instead, we should get a naming ("invalid name") exception when the datasource is added.


  was:
Using a datasource name like "java:jdbc/eFpDataSource" in a persistence.xml doesn't seem to work.  We seem to start to deploy the datasource but cannot resolve the service lookup.

Deploying an application that contains a persistence unit reference to the above datasource (see forum post for efp.ear zip), leads to the following server.log output:

07:20:11,374 DEBUG [org.jboss.as.connector.deployer.dsdeployer] (MSC service thread 1-1) Adding datasource: java:/java:jdbc/eFpDataSource

07:20:11,378 TRACE [org.jboss.as.naming.service.BinderService] (MSC service thread 1-2) Bound resource jdbc/eFpDataSource into naming store org.jboss.as.naming.InMemoryNamingStore at 65499154

   New missing/unsatisfied dependencies:
      service jboss.naming.context.java.java:jdbc/eFpDataSource (missing)


    Forum Reference: http://community.jboss.org/message/612948, http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/thread.html#2879  (was: http://community.jboss.org/message/612948, http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/thread.html#2879)


> relative names that start with "java:XXX", XXX must be: "comp", "module", "app", "global","jboss"
> -------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1171
>                 URL: https://issues.jboss.org/browse/AS7-1171
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 7.0.0.CR1
>            Reporter: Scott Marlow
>            Assignee: John Bailey
>             Fix For: 7.0.0.Final
>
>
> Using a datasource name like "java:jdbc/eFpDataSource" in a persistence.xml doesn't seem to work.  We seem to start to deploy the datasource but cannot resolve the service lookup.
> Deploying an application that contains a persistence unit reference to the above datasource (see forum post for efp.ear zip), leads to the following server.log output:
> 07:20:11,374 DEBUG [org.jboss.as.connector.deployer.dsdeployer] (MSC service thread 1-1) Adding datasource: java:/java:jdbc/eFpDataSource
> 07:20:11,378 TRACE [org.jboss.as.naming.service.BinderService] (MSC service thread 1-2) Bound resource jdbc/eFpDataSource into naming store org.jboss.as.naming.InMemoryNamingStore at 65499154
> And the application (includes persistence.xml reference to EfpDataSource) fails to deploy, with the following:
>    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.java:jdbc/eFpDataSource (missing)
> Instead, we should get a naming ("invalid name") exception when the datasource is added.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul  2 20:43:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Sat, 2 Jul 2011 20:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1175) Upgrade Infinispan to
	5.0.0.CR7
Message-ID: <1350022527.32874.1309653803636.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Upgrade Infinispan to 5.0.0.CR7
-------------------------------

                 Key: AS7-1175
                 URL: https://issues.jboss.org/browse/AS7-1175
             Project: Application Server 7
          Issue Type: Component  Upgrade
          Components: Clustering
    Affects Versions: 7.0.0.CR1
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 7.0.0.Final


Contains yet another minor API change affecting EvictionListeners

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul  3 03:34:23 2011
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sun, 3 Jul 2011 03:34:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2866) Support for
 Metadata in Decision Tables
In-Reply-To: <2006497934.2016.1294675489585.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1751896602.32951.1309678463896.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Mark Proctor updated JBRULES-2866:
----------------------------------

      Fix Version/s: 5.2.1.Final
                         (was: FUTURE)
    Forum Reference: http://lists.jboss.org/pipermail/rules-users/2011-January/018013.html  (was: http://lists.jboss.org/pipermail/rules-users/2011-January/018013.html)


> Support for Metadata in Decision Tables
> ---------------------------------------
>
>                 Key: JBRULES-2866
>                 URL: https://issues.jboss.org/browse/JBRULES-2866
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-decisiontables
>    Affects Versions: 5.1.1.FINAL
>         Environment: All
>            Reporter: Jason Mihalick
>            Assignee: Tihomir Surdilovic
>             Fix For: 5.2.1.Final
>
>
> Please add support for Metadata annotations in decision tables.  Discussion thread here: http://drools-java-rules-engine.46999.n3.nabble.com/Need-help-with-Decision-Table-Conditions-td2195003.html

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul  3 03:36:23 2011
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sun, 3 Jul 2011 03:36:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2866) Support for
 Metadata in Decision Tables
In-Reply-To: <2006497934.2016.1294675489585.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1126245777.32957.1309678583817.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Mark Proctor updated JBRULES-2866:
----------------------------------

      Fix Version/s: 5.2.0.Final
                         (was: 5.2.1.Final)
    Forum Reference: http://lists.jboss.org/pipermail/rules-users/2011-January/018013.html  (was: http://lists.jboss.org/pipermail/rules-users/2011-January/018013.html)


> Support for Metadata in Decision Tables
> ---------------------------------------
>
>                 Key: JBRULES-2866
>                 URL: https://issues.jboss.org/browse/JBRULES-2866
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-decisiontables
>    Affects Versions: 5.1.1.FINAL
>         Environment: All
>            Reporter: Jason Mihalick
>            Assignee: Tihomir Surdilovic
>             Fix For: 5.2.0.Final
>
>
> Please add support for Metadata annotations in decision tables.  Discussion thread here: http://drools-java-rules-engine.46999.n3.nabble.com/Need-help-with-Decision-Table-Conditions-td2195003.html

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul  3 03:36:24 2011
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sun, 3 Jul 2011 03:36:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-2866) Support for
 Metadata in Decision Tables
In-Reply-To: <2006497934.2016.1294675489585.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1553632529.32961.1309678584047.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Mark Proctor resolved JBRULES-2866.
-----------------------------------

    Resolution: Done


> Support for Metadata in Decision Tables
> ---------------------------------------
>
>                 Key: JBRULES-2866
>                 URL: https://issues.jboss.org/browse/JBRULES-2866
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-decisiontables
>    Affects Versions: 5.1.1.FINAL
>         Environment: All
>            Reporter: Jason Mihalick
>            Assignee: Tihomir Surdilovic
>             Fix For: 5.2.0.Final
>
>
> Please add support for Metadata annotations in decision tables.  Discussion thread here: http://drools-java-rules-engine.46999.n3.nabble.com/Need-help-with-Decision-Table-Conditions-td2195003.html

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul  3 04:11:24 2011
From: jira-events at lists.jboss.org (Bharat Patil (JIRA))
Date: Sun, 3 Jul 2011 04:11:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2384) Unable to
 process deployment descriptor for context'/drools-server'
In-Reply-To: <1461018875.1261042170899.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <878288445.32972.1309680684092.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Bharat Patil commented on JBRULES-2384:
---------------------------------------

Please set the JAVA_HOME in environment variable , nothing but u r jdk path. 

> Unable to process deployment descriptor for context'/drools-server'
> -------------------------------------------------------------------
>
>                 Key: JBRULES-2384
>                 URL: https://issues.jboss.org/browse/JBRULES-2384
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: All
>         Environment: windows
>            Reporter: Megha Shetty
>            Assignee: Mark Proctor
>
> I am getting the following error when i am trying to deploy drools-server.war through jboss.
> Unable to process deployment descriptor for context'/drools-server'
> Following is the complete log when i am starting the jboss server
> JAVA_HOME is not set.  Unexpected results may occur.
> Set JAVA_HOME to the directory of your local JDK to avoid this message.
> ===============================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: E:\Eclipse Europa\jboss-4.2.3.GA
>   JAVA: java
>   JAVA_OPTS:  -Dprogram.name=run.bat -Xms128m -Xmx512m -Dsun.rmi.dgc.client.gcIn
> terval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000
>   CLASSPATH: E:\Eclipse Europa\jboss-4.2.3.GA\bin\run.jar
> ===============================================================================
> 14:35:43,295 INFO  [Server] Starting JBoss (MX MicroKernel)...
> 14:35:43,295 INFO  [Server] Release ID: JBoss [Trinity] 4.2.3.GA (build: SVNTag=
> JBoss_4_2_3_GA date=200807181417)
> 14:35:43,295 INFO  [Server] Home Dir: E:\Eclipse Europa\jboss-4.2.3.GA
> 14:35:43,295 INFO  [Server] Home URL: file:/E:/Eclipse Europa/jboss-4.2.3.GA/
> 14:35:43,295 INFO  [Server] Patch URL: null
> 14:35:43,295 INFO  [Server] Server Name: default
> 14:35:43,295 INFO  [Server] Server Home Dir: E:\Eclipse Europa\jboss-4.2.3.GA\se
> rver\default
> 14:35:43,311 INFO  [Server] Server Home URL: file:/E:/Eclipse Europa/jboss-4.2.3
> .GA/server/default/
> 14:35:43,311 INFO  [Server] Server Log Dir: E:\Eclipse Europa\jboss-4.2.3.GA\ser
> ver\default\log
> 14:35:43,311 INFO  [Server] Server Temp Dir: E:\Eclipse Europa\jboss-4.2.3.GA\se
> rver\default\tmp
> 14:35:43,311 INFO  [Server] Root Deployment Filename: jboss-service.xml
> 14:35:43,482 INFO  [ServerInfo] Java version: 1.6.0,Sun Microsystems Inc.
> 14:35:43,482 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.6.0-b105,S
> un Microsystems Inc.
> 14:35:43,498 INFO  [ServerInfo] OS-System: Windows XP 5.1,x86
> 14:35:43,857 INFO  [Server] Core system initialized
> 14:35:45,670 INFO  [WebService] Using RMI server codebase: http://127.0.0.1:8083
> /
> 14:35:45,670 INFO  [Log4jService$URLWatchTimerTask] Configuring from URL: resour
> ce:jboss-log4j.xml
> 14:35:46,513 INFO  [TransactionManagerService] JBossTS Transaction Service (JTA
> version) - JBoss Inc.
> 14:35:46,513 INFO  [TransactionManagerService] Setting up property manager MBean
>  and JMX layer
> 14:35:46,701 INFO  [TransactionManagerService] Starting recovery manager
> 14:35:46,748 INFO  [TransactionManagerService] Recovery manager started
> 14:35:46,748 INFO  [TransactionManagerService] Binding TransactionManager JNDI R
> eference
> 14:35:50,263 INFO  [EJB3Deployer] Starting java:comp multiplexer
> 14:35:51,607 INFO  [NativeServerConfig] JBoss Web Services - Native
> 14:35:51,622 INFO  [NativeServerConfig] jbossws-3.0.1-native-2.0.4.GA (build=200
> 803312044)
> 14:35:52,466 INFO  [Embedded] Catalina naming disabled
> 14:35:52,575 INFO  [AprLifecycleListener] The Apache Tomcat Native library which
>  allows optimal performance in production environments was not found on the java
> .library.path: C:\WINDOWS\system32;.;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32
> ;C:\WINDOWS;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
> 14:35:52,607 INFO  [Http11Protocol] Initializing Coyote HTTP/1.1 on http-127.0.0
> .1-8080
> 14:35:52,607 INFO  [AjpProtocol] Initializing Coyote AJP/1.3 on ajp-127.0.0.1-80
> 09
> 14:35:52,607 INFO  [Catalina] Initialization processed in 147 ms
> 14:35:52,607 INFO  [StandardService] Starting service jboss.web
> 14:35:52,607 INFO  [StandardEngine] Starting Servlet Engine: JBossWeb/2.0.1.GA
> 14:35:52,638 INFO  [Catalina] Server startup in 24 ms
> 14:35:52,794 INFO  [TomcatDeployer] deploy, ctxPath=/, warUrl=.../deploy/jboss-w
> eb.deployer/ROOT.war/
> 14:35:53,560 INFO  [TomcatDeployer] deploy, ctxPath=/invoker, warUrl=.../deploy/
> http-invoker.sar/invoker.war/
> 14:35:53,669 INFO  [TomcatDeployer] deploy, ctxPath=/jbossws, warUrl=.../deploy/
> jbossws.sar/jbossws-context.war/
> 14:35:53,732 INFO  [TomcatDeployer] deploy, ctxPath=/jbossmq-httpil, warUrl=.../
> deploy/jms/jbossmq-httpil.sar/jbossmq-httpil.war/
> 14:35:54,153 INFO  [TomcatDeployer] deploy, ctxPath=/web-console, warUrl=.../dep
> loy/management/console-mgr.sar/web-console.war/
> 14:35:54,513 INFO  [MailService] Mail Service bound to java:/Mail
> 14:35:54,669 INFO  [RARDeployment] Required license terms exist, view META-INF/r
> a.xml in .../deploy/jboss-ha-local-jdbc.rar
> 14:35:54,763 INFO  [RARDeployment] Required license terms exist, view META-INF/r
> a.xml in .../deploy/jboss-ha-xa-jdbc.rar
> 14:35:54,856 INFO  [RARDeployment] Required license terms exist, view META-INF/r
> a.xml in .../deploy/jboss-local-jdbc.rar
> 14:35:54,935 INFO  [RARDeployment] Required license terms exist, view META-INF/r
> a.xml in .../deploy/jboss-xa-jdbc.rar
> 14:35:55,544 INFO  [RARDeployment] Required license terms exist, view META-INF/r
> a.xml in .../deploy/jms/jms-ra.rar
> 14:35:55,716 INFO  [RARDeployment] Required license terms exist, view META-INF/r
> a.xml in .../deploy/mail-ra.rar
> 14:35:55,903 INFO  [RARDeployment] Required license terms exist, view META-INF/r
> a.xml in .../deploy/quartz-ra.rar
> 14:35:55,903 INFO  [QuartzResourceAdapter] start quartz!!!
> 14:35:55,950 INFO  [SimpleThreadPool] Job execution threads will use class loade
> r of thread: main
> 14:35:55,950 INFO  [QuartzScheduler] Quartz Scheduler v.1.5.2 created.
> 14:35:55,966 INFO  [RAMJobStore] RAMJobStore initialized.
> 14:35:55,966 INFO  [StdSchedulerFactory] Quartz scheduler 'DefaultQuartzSchedule
> r' initialized from default resource file in Quartz package: 'quartz.properties'
> 14:35:55,966 INFO  [StdSchedulerFactory] Quartz scheduler version: 1.5.2
> 14:35:55,966 INFO  [QuartzScheduler] Scheduler DefaultQuartzScheduler_$_NON_CLUS
> TERED started.
> 14:35:56,966 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jb
> oss.jca:service=DataSourceBinding,name=DefaultDS' to JNDI name 'java:DefaultDS'
> 14:35:57,200 INFO  [A] Bound to JNDI name: queue/A
> 14:35:57,200 INFO  [B] Bound to JNDI name: queue/B
> 14:35:57,200 INFO  [C] Bound to JNDI name: queue/C
> 14:35:57,200 INFO  [D] Bound to JNDI name: queue/D
> 14:35:57,200 INFO  [ex] Bound to JNDI name: queue/ex
> 14:35:57,216 INFO  [testTopic] Bound to JNDI name: topic/testTopic
> 14:35:57,216 INFO  [securedTopic] Bound to JNDI name: topic/securedTopic
> 14:35:57,216 INFO  [testDurableTopic] Bound to JNDI name: topic/testDurableTopic
> 14:35:57,216 INFO  [testQueue] Bound to JNDI name: queue/testQueue
> 14:35:57,231 INFO  [UILServerILService] JBossMQ UIL service available at : /127.
> 0.0.1:8093
> 14:35:57,263 INFO  [DLQ] Bound to JNDI name: queue/DLQ
> 14:35:57,341 INFO  [ConnectionFactoryBindingService] Bound ConnectionManager 'jb
> oss.jca:service=ConnectionFactoryBinding,name=JmsXA' to JNDI name 'java:JmsXA'
> 14:35:57,794 INFO  [TomcatDeployer] deploy, ctxPath=/drools-guvnor, warUrl=.../d
> eploy/drools-guvnor.war/
> 14:36:08,965 INFO  [TomcatDeployer] deploy, ctxPath=/drools-server, warUrl=.../d
> eploy/drools-server.war/
> 14:36:09,012 WARN  [config] Unable to process deployment descriptor for context
> '/drools-server'
> 14:36:09,371 INFO  [TomcatDeployer] deploy, ctxPath=/jmx-console, warUrl=.../dep
> loy/jmx-console.war/
> 14:36:09,496 INFO  [Http11Protocol] Starting Coyote HTTP/1.1 on http-127.0.0.1-8
> 080
> 14:36:09,512 INFO  [AjpProtocol] Starting Coyote AJP/1.3 on ajp-127.0.0.1-8009
> 14:36:09,512 INFO  [Server] JBoss (MX MicroKernel) [4.2.3.GA (build: SVNTag=JBos
> s_4_2_3_GA date=200807181417)] Started in 26s:201ms

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul  3 13:20:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sun, 3 Jul 2011 13:20:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-423) Remote EJB (non-IIOP)
In-Reply-To: <1343169786.30372.1300298686427.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2059727912.33046.1309713623855.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai updated AS7-423:
-----------------------------

    Component/s: EJB


> Remote EJB (non-IIOP)
> ---------------------
>
>                 Key: AS7-423
>                 URL: https://issues.jboss.org/browse/AS7-423
>             Project: Application Server 7
>          Issue Type: Task
>          Components: EJB
>            Reporter: David Lloyd
>             Fix For: 7.1.0.Alpha1
>
>
> Parent task for remote EJB integration.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul  3 14:18:23 2011
From: jira-events at lists.jboss.org (Jay Balunas (JIRA))
Date: Sun, 3 Jul 2011 14:18:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-205) Invalid async
 context for servlet: Atmosphere Async Servlet on JBoss Web
In-Reply-To: <1369266963.32802.1309619303616.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <367819255.33054.1309717103845.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jay Balunas updated JBWEB-205:
------------------------------

             Priority: Critical  (was: Major)
    Affects Version/s: JBossWeb-7.0.0.CR1
          Component/s: Core


The JBoss web version in 7.0.0.CR1 seems to be jbossweb-7.0.0.CR4.  However there is no CR4 listed in the "Affects Version" so I set to 7.0.0.CR1.

I've also upped the severity of this issue, because it would be a critical issue if RichFaces push can not work with AS7.  The RichFaces team is more than willing to assist with this issue however possible.  

> Invalid async context for servlet: Atmosphere Async  Servlet on JBoss Web
> -------------------------------------------------------------------------
>
>                 Key: JBWEB-205
>                 URL: https://issues.jboss.org/browse/JBWEB-205
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-7.0.0.CR1
>         Environment: Firefox 4.0.1 / Chromium 12 
> AS 6.0.0.Final / 6.1.0-SNAPSHOT / AS 7.0.0.CR1 
> Atmosphere 0.7.1/0.7.2 
>            Reporter: Luk?? Fry?
>            Assignee: Remy Maucherat
>            Priority: Critical
>         Attachments: push-jms.war
>
>
> Source of sample for reproduction:
> https://github.com/lfryc/push-jms/commit/9cee160570e049ca4783e1fcbdac25ffef1b10b7
> {code}
> 16:08:28,467 ERROR [org.apache.catalina.connector.CoyoteAdapter] (http-localhost-127.0.0.1-8080-7) An exception or error occurred in the container during the request processing: java.lang.IllegalStateException: Invalid async context for servlet AutoRegisteredPushServlet
> 	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:643) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:402) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:183) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:246) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:128) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:265) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11Processor.event(Http11Processor.java:757) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.event(Http11Protocol.java:615) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:938) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at java.lang.Thread.run(Thread.java:636) [:1.6.0_20]
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Sun Jul  3 15:58:23 2011
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Sun, 3 Jul 2011 15:58:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-205) Invalid async
 context for servlet: Atmosphere Async Servlet on JBoss Web
In-Reply-To: <1369266963.32802.1309619303616.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <288982731.33064.1309723103820.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Remy Maucherat commented on JBWEB-205:
--------------------------------------

Your WAR does not deploy for me:
21:55:06,020 INFO  [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-3) Unsanitized stacktrace from failed start...: com.google.common.collect.ComputationException: javax.faces.FacesException: Name 'ConnectionFactory' not found in context ''

> Invalid async context for servlet: Atmosphere Async  Servlet on JBoss Web
> -------------------------------------------------------------------------
>
>                 Key: JBWEB-205
>                 URL: https://issues.jboss.org/browse/JBWEB-205
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-7.0.0.CR1
>         Environment: Firefox 4.0.1 / Chromium 12 
> AS 6.0.0.Final / 6.1.0-SNAPSHOT / AS 7.0.0.CR1 
> Atmosphere 0.7.1/0.7.2 
>            Reporter: Luk?? Fry?
>            Assignee: Remy Maucherat
>            Priority: Critical
>         Attachments: push-jms.war
>
>
> Source of sample for reproduction:
> https://github.com/lfryc/push-jms/commit/9cee160570e049ca4783e1fcbdac25ffef1b10b7
> {code}
> 16:08:28,467 ERROR [org.apache.catalina.connector.CoyoteAdapter] (http-localhost-127.0.0.1-8080-7) An exception or error occurred in the container during the request processing: java.lang.IllegalStateException: Invalid async context for servlet AutoRegisteredPushServlet
> 	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:643) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:402) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:183) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:246) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:128) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:265) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11Processor.event(Http11Processor.java:757) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.event(Http11Protocol.java:615) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:938) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at java.lang.Thread.run(Thread.java:636) [:1.6.0_20]
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul  4 00:45:23 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Mon, 4 Jul 2011 00:45:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1883) Server side
 failover may cause ClientConsumer.waitForOnMessageToComplete() to hang
Message-ID: <1557636092.33242.1309754723980.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Server side failover may cause ClientConsumer.waitForOnMessageToComplete() to hang
----------------------------------------------------------------------------------

                 Key: JBMESSAGING-1883
                 URL: https://issues.jboss.org/browse/JBMESSAGING-1883
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Clustering
    Affects Versions: 1.4.8.SP1, 1.4.0.SP3.CP13
            Reporter: Yong Hao Gao
            Assignee: Yong Hao Gao
             Fix For: 1.4.0.SP3.CP14, 1.4.8.SP2


When server side failover happens, the failover node will get "node left" notification from jgroups as well as "connection broken" notification from remoting on the connections through which message suckers are created. The listeners of the two notifications are executed concurrently and both try to close related resources. The "node left" listener performs failover for the dead node, where it closes all message suckers (underneath the ClientConsumers). The "connection broken" listener will close the related connection/session/consumer. If 

1. in failover the ClientConsumer.close() is called but before waitForOnMessageToComplete() is called, 
2. the session is being closed by the 'connection broken' listener.
3. when the waitForOnMessageToComplete() is called, it puts a 'Closer' task to executor and wait for it. However at that time the executor has been closed already in step 2. So the 'Closer' task will never get executed and it will wait forever.



--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 01:28:23 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Mon, 4 Jul 2011 01:28:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1883) Server side
 failover may cause ClientConsumer.waitForOnMessageToComplete() to hang
In-Reply-To: <1557636092.33242.1309754723980.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2096514907.33262.1309757303673.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao commented on JBMESSAGING-1883:
-------------------------------------------

The fix:

Add a state flag to the Closer object. If the Closer is added to executor that is already shut down, set the flag. In waitForOnMessageToComplete() it checks the flag, if the flag is set then don't wait for it.



> Server side failover may cause ClientConsumer.waitForOnMessageToComplete() to hang
> ----------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1883
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1883
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP13, 1.4.8.SP1
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP14, 1.4.8.SP2
>
>
> When server side failover happens, the failover node will get "node left" notification from jgroups as well as "connection broken" notification from remoting on the connections through which message suckers are created. The listeners of the two notifications are executed concurrently and both try to close related resources. The "node left" listener performs failover for the dead node, where it closes all message suckers (underneath the ClientConsumers). The "connection broken" listener will close the related connection/session/consumer. If 
> 1. in failover the ClientConsumer.close() is called but before waitForOnMessageToComplete() is called, 
> 2. the session is being closed by the 'connection broken' listener.
> 3. when the waitForOnMessageToComplete() is called, it puts a 'Closer' task to executor and wait for it. However at that time the executor has been closed already in step 2. So the 'Closer' task will never get executed and it will wait forever.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 02:49:24 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Mon, 4 Jul 2011 02:49:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1176) Update to Arquillian
 OSGi 1.0.0.CR2 or later
Message-ID: <1894087009.33300.1309762164012.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Update to Arquillian OSGi 1.0.0.CR2 or later
--------------------------------------------

                 Key: AS7-1176
                 URL: https://issues.jboss.org/browse/AS7-1176
             Project: Application Server 7
          Issue Type: Task
            Reporter: Thomas Diesler
            Assignee: Thomas Diesler
             Fix For: 7.0.0.Final




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 03:13:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Mon, 4 Jul 2011 03:13:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1176) Update to
 Arquillian OSGi 1.0.0.CR2 or later
In-Reply-To: <1894087009.33300.1309762164012.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1568506902.33327.1309763603634.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Thomas Diesler commented on AS7-1176:
-------------------------------------

Verified in context of AS7

cc4ba75 Cleanup osgi container dependencies. Attempt to reuse embedded tests for remote container
4cd62a3 Fix remote osgi container
bd9608b Add checkstyle validation
f699101 Format/Organize Imports using AS7 style
4e19ff2 ARQ-461 prepare for next development iteration
77d98d1 ARQ-461 prepare release 1.0.0.CR1


> Update to Arquillian OSGi 1.0.0.CR2 or later
> --------------------------------------------
>
>                 Key: AS7-1176
>                 URL: https://issues.jboss.org/browse/AS7-1176
>             Project: Application Server 7
>          Issue Type: Task
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For: 7.0.0.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 05:18:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Mon, 4 Jul 2011 05:18:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1177) JavaMail not available
Message-ID: <371450412.33446.1309771103714.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

JavaMail not available
----------------------

                 Key: AS7-1177
                 URL: https://issues.jboss.org/browse/AS7-1177
             Project: Application Server 7
          Issue Type: Bug
          Components: Modules
    Affects Versions: 7.0.0.CR1
            Reporter: Juergen Zimmermann


JavaMail cannot be used as it was in JBossAS 6 and earlier.

1) I tried as in JBoss 6:
@Resource(mappedName = "java:Mail")
private Session mailer;

... and got this logging info within the Arquillian tests:
11:12:08,454 INFO  [org.jboss.as.server.controller] (pool-1-thread-48) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.naming.context.java.comp.\"test.ear\".test.KundenverwaltungListener.\"env/de.swe2.kundenverwaltung.service.KundenverwaltungListener/mailer\".jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.8","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Dao.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.ValidationService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Kundenverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Artikelverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.FileStore.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.RolesService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.BestellverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.PasswordService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".jndiDependencyService","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Bestellverwaltung.START"]}
11:12:08,468 INFO  [org.jboss.jpa] (MSC service thread 1-1) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
11:12:08,470 INFO  [org.jboss.weld] (MSC service thread 1-1) Stopping weld service

2) I tried
@Resource
private Session mailer;

... and got this logging info within the Arquillian tests:
11:09:20,085 INFO  [org.jboss.as.server.controller] (pool-1-thread-46) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START"]}
11:09:20,094 INFO  [org.jboss.jpa] (MSC service thread 1-2) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
11:09:20,098 INFO  [org.jboss.weld] (MSC service thread 1-2) Stopping weld service


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul  4 05:43:23 2011
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 4 Jul 2011 05:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1178) add test case for
 removing and re-adding datasource with same name
Message-ID: <1867620301.33457.1309772603681.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

add test case for removing and re-adding datasource with same name
------------------------------------------------------------------

                 Key: AS7-1178
                 URL: https://issues.jboss.org/browse/AS7-1178
             Project: Application Server 7
          Issue Type: Sub-task
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 05:47:23 2011
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 4 Jul 2011 05:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1179) add test case for
 JDCB driver read-resource-description opreation
Message-ID: <1076010829.33461.1309772843746.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

add test case for JDCB driver read-resource-description opreation
-----------------------------------------------------------------

                 Key: AS7-1179
                 URL: https://issues.jboss.org/browse/AS7-1179
             Project: Application Server 7
          Issue Type: Sub-task
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 05:47:23 2011
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 4 Jul 2011 05:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1179) add test case for
 JDCB driver read-resource-description operation
In-Reply-To: <1076010829.33461.1309772843746.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <95678174.33463.1309772843831.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jeff Zhang updated AS7-1179:
----------------------------

    Summary: add test case for JDCB driver read-resource-description operation  (was: add test case for JDCB driver read-resource-description opreation)


> add test case for JDCB driver read-resource-description operation
> -----------------------------------------------------------------
>
>                 Key: AS7-1179
>                 URL: https://issues.jboss.org/browse/AS7-1179
>             Project: Application Server 7
>          Issue Type: Sub-task
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 05:49:23 2011
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Mon, 4 Jul 2011 05:49:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1180) add test case for
 read installed drivers list
Message-ID: <926858532.33466.1309772963809.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

add test case for read installed drivers list
---------------------------------------------

                 Key: AS7-1180
                 URL: https://issues.jboss.org/browse/AS7-1180
             Project: Application Server 7
          Issue Type: Sub-task
            Reporter: Jeff Zhang
            Assignee: Jeff Zhang
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 05:53:23 2011
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Mon, 4 Jul 2011 05:53:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-205) Invalid async
 context for servlet: Atmosphere Async Servlet on JBoss Web
In-Reply-To: <1369266963.32802.1309619303616.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2035612889.33476.1309773203910.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Remy Maucherat commented on JBWEB-205:
--------------------------------------

I was able to run the WAR on the full EE config in the end. Reproducing is not easy and intermittent at best, and I have not been able to identify the cause of the issue. I wanted to compare with what happened when native was installed, but Atmosphere then switches to using the event API rather than Servlet 3, which does not use the same code paths [and I didn't see any problem, but I am not certain since the problem was very intermittent for the other connector].

I am replacing the exception with a log message, since the exception had little benefit and prevented cleanup, while this only appears to be an extra event with no meaning for Servlet 3 async. Beyond that, I have no idea at this time on how to improve this.

> Invalid async context for servlet: Atmosphere Async  Servlet on JBoss Web
> -------------------------------------------------------------------------
>
>                 Key: JBWEB-205
>                 URL: https://issues.jboss.org/browse/JBWEB-205
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-7.0.0.CR1
>         Environment: Firefox 4.0.1 / Chromium 12 
> AS 6.0.0.Final / 6.1.0-SNAPSHOT / AS 7.0.0.CR1 
> Atmosphere 0.7.1/0.7.2 
>            Reporter: Luk?? Fry?
>            Assignee: Remy Maucherat
>            Priority: Critical
>         Attachments: push-jms.war
>
>
> Source of sample for reproduction:
> https://github.com/lfryc/push-jms/commit/9cee160570e049ca4783e1fcbdac25ffef1b10b7
> {code}
> 16:08:28,467 ERROR [org.apache.catalina.connector.CoyoteAdapter] (http-localhost-127.0.0.1-8080-7) An exception or error occurred in the container during the request processing: java.lang.IllegalStateException: Invalid async context for servlet AutoRegisteredPushServlet
> 	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:643) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:402) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:183) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:246) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:128) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:265) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11Processor.event(Http11Processor.java:757) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.event(Http11Protocol.java:615) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:938) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at java.lang.Thread.run(Thread.java:636) [:1.6.0_20]
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul  4 06:10:24 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Mon, 4 Jul 2011 06:10:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1164) add jdbc-driver :
 documentation incomplete or misleading
In-Reply-To: <2061849607.31723.1309511903626.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <888613799.33486.1309774224871.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Rupp commented on AS7-1164:
---------------------------------

So after discussion on irc:

[11:53:14] <+maeste> pilhuhn: you can't use the add command for a deployed driver
[11:53:15] <+pilhuhn> (obviously)
[11:53:23] <+pilhuhn> it is not deployed
[11:53:30] ChanServ sets mode +v AndyTaylor
[11:53:38] <+maeste> pilhuhn: yup, but it isn't a module
[11:53:44] <+pilhuhn> at least not to /subystem=datasources/jdbc-driver
[11:53:52] <+maeste> pilhuhn: add is only for module loaded driversers
[12:02:48] <+maeste> pilhuhn: :read-children give the correct answer because the only drivers present at domain level are module's one
[12:03:08] <+pilhuhn> and for standalone?
[12:03:18] <+maeste> pilhuhn: there is a specific operation installed-drivers-list
[12:03:40] <+maeste> pilhuhn: I said domain, I mean at profile level
[12:04:05] <+maeste> pilhuhn: if you use the installed-drivers-list you should see all drivers
[12:04:16] <+maeste> pilhuhn: I'm seeing it righ now:
[12:04:31] <+maeste> pilhuhn: [standalone at localhost:9999 /] /subsystem=datasources:installed-drivers-list
12:04:36] <+pilhuhn> so I can use such a driver that shows up at "installed-drivers-list" -- even if it does not show up under subsystem=datasources,jdbc-driver=* ?
[12:05:23] <+maeste> pilhuhn: yup
[12:05:25] <+maeste> pilhuhn: the operation have been done exactly for that
[12:05:27] <+maeste> pilhuhn: looking for the jira with brian's explanation
[12:05:29] <+maeste> pilhuhn: better than mine :)
[12:05:50] <+pilhuhn> So ss=ds/jdbc-drivers is basically useless for normal usage
[12:06:40] <+maeste> pilhuhn: yup if you have hot deployed drivers
[12:06:53] <+maeste> pilhuhn: it's fine only if you have only preloaded module
[12:06:59] ChanServ sets mode +v kkhan
[12:07:03] <+pilhuhn> even for the others ,as they all show up in installed-drivers-lsit
[12:08:14] <+maeste> pilhuhn: here you have the discussion https://issues.jboss.org/browse/AS7-328

> add jdbc-driver : documentation incomplete or misleading
> --------------------------------------------------------
>
>                 Key: AS7-1164
>                 URL: https://issues.jboss.org/browse/AS7-1164
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.0.0.CR1
>            Reporter: Heiko Rupp
>            Assignee: Brian Stansberry
>
> I want to add a jdbc driver to a profile. The driver has been uploaded to /deployment
> [domain at localhost:9999 subsystem=datasources] pwd
> /profile=default/subsystem=datasources
> [domain at localhost:9999 subsystem=datasources] ./jdbc-driver=postgres9:add(driver-name=postgres9,deployment-name=postgresql-9.0-801.jdbc4.jar,driver-class-name=org.postgresql.Driver)
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "Operation handler failed: java.util.NoSuchElementException: No child 'driver-module-name' exists"},
>     "rolled-back" => true
> }
> Documentation says:
> [domain at localhost:9999 jdbc-driver=h2] :read-operation-description(name=add)                 
> {
>     "outcome" => "success",
>     "result" => {
>         "operation-name" => "add",
>         "description" => "Adds a new JDBC driver service",
>         "attributes" => {
>             "driver-name" => {
>                 "description" => "The symbolic name of this driver used to reference it in the register",
>                 "type" => STRING,
>                 "required" => true
>             },
>             "deployment-name" => {
>                 "description" => "The name of the deployment unit from which the driver was loaded, if it was loaded from a deployment",
>                 "type" => STRING
>             },
>             "driver-module-name" => {
>                 "description" => "The name of the module from which the driver was loaded, if it was loaded from the module path",
>                 "type" => STRING
>             },
>             "module-slot" => {
>                 "description" => "The slot of the module from which the driver was loaded, if it was loaded from the module path",
>                 "type" => STRING
>             },
>             "driver-class-name" => {
>                 "description" => "The fully qualified class name of the driver's implementation of java.sql.Driver",
>                 "type" => STRING
>             },
>             "driver-major-version" => {
>                 "description" => "The driver's major version number",
>                 "type" => INT
>             },
>             "driver-minor-version" => {
>                 "description" => "The driver's minor version number",
>                 "type" => INT
>             },
>             "jdbc-compliant" => {
>                 "description" => "Whether or not the driver is JDBC compliant",
>                 "type" => BOOLEAN
>             }
>         }
>     }
> }
> Here, only the driver-name is required.
> For driver-module-name it says "if loaded from module", which I read as "optional".
> Obviously from above error message, this is not optional

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 06:20:23 2011
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Mon, 4 Jul 2011 06:20:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-205) Invalid async
 context for servlet: Atmosphere Async Servlet on JBoss Web
In-Reply-To: <1369266963.32802.1309619303616.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <342669302.33495.1309774823748.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Remy Maucherat commented on JBWEB-205:
--------------------------------------

Letting the test run for a while, I also got this error:
12:09:55,884 SEVERE [org.atmosphere.cpr.DefaultBroadcaster] (Atmosphere-BroadcasterConfig-0) failed to submit broadcast handler runnable to broadcast executor service: java.lang.OutOfMemoryError: unable to create new native thread
	at java.lang.Thread.start0(Native Method) [:1.6.0_22]
	at java.lang.Thread.start(Thread.java:657) [:1.6.0_22]
	at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:943) [:1.6.0_22]
	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1336) [:1.6.0_22]
	at org.atmosphere.cpr.DefaultBroadcaster.executeAsyncWrite(DefaultBroadcaster.java:431) [atmosphere-runtime-0.7.1.jar:]
	at org.atmosphere.cpr.DefaultBroadcaster.push(DefaultBroadcaster.java:383) [atmosphere-runtime-0.7.1.jar:]
	at org.atmosphere.cpr.DefaultBroadcaster$2.run(DefaultBroadcaster.java:321) [atmosphere-runtime-0.7.1.jar:]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [:1.6.0_22]
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [:1.6.0_22]
	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [:1.6.0_22]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.6.0_22]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.6.0_22]
	at java.lang.Thread.run(Thread.java:679) [:1.6.0_22]


> Invalid async context for servlet: Atmosphere Async  Servlet on JBoss Web
> -------------------------------------------------------------------------
>
>                 Key: JBWEB-205
>                 URL: https://issues.jboss.org/browse/JBWEB-205
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-7.0.0.CR1
>         Environment: Firefox 4.0.1 / Chromium 12 
> AS 6.0.0.Final / 6.1.0-SNAPSHOT / AS 7.0.0.CR1 
> Atmosphere 0.7.1/0.7.2 
>            Reporter: Luk?? Fry?
>            Assignee: Remy Maucherat
>            Priority: Critical
>         Attachments: push-jms.war
>
>
> Source of sample for reproduction:
> https://github.com/lfryc/push-jms/commit/9cee160570e049ca4783e1fcbdac25ffef1b10b7
> {code}
> 16:08:28,467 ERROR [org.apache.catalina.connector.CoyoteAdapter] (http-localhost-127.0.0.1-8080-7) An exception or error occurred in the container during the request processing: java.lang.IllegalStateException: Invalid async context for servlet AutoRegisteredPushServlet
> 	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:643) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:402) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:183) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:246) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:128) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:265) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11Processor.event(Http11Processor.java:757) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.event(Http11Protocol.java:615) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:938) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at java.lang.Thread.run(Thread.java:636) [:1.6.0_20]
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul  4 06:53:23 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Mon, 4 Jul 2011 06:53:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMESSAGING-1882) Missing
 jbossweb.jar in JBM test suite
In-Reply-To: <2017882900.21667.1309164625093.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1130823584.33547.1309776803829.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao resolved JBMESSAGING-1882.
---------------------------------------

    Resolution: Done


> Missing jbossweb.jar in JBM test suite
> --------------------------------------
>
>                 Key: JBMESSAGING-1882
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1882
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.8.SP1
>            Reporter: Miroslav Novak
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.8.SP2
>
>         Attachments: jbossweb.jar
>
>
> Hi Howard,
> when I've started clustering tests target then all of them failed because jbossweb.jar is missing. Could you modify our ant scripts to download it and put to classpath when for "tests" target, please.
> Thank you,
> Mirek

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 06:53:24 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Mon, 4 Jul 2011 06:53:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1882) Missing
 jbossweb.jar in JBM test suite
In-Reply-To: <2017882900.21667.1309164625093.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1580104818.33552.1309776804091.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao closed JBMESSAGING-1882.
-------------------------------------



> Missing jbossweb.jar in JBM test suite
> --------------------------------------
>
>                 Key: JBMESSAGING-1882
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1882
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.8.SP1
>            Reporter: Miroslav Novak
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.8.SP2
>
>         Attachments: jbossweb.jar
>
>
> Hi Howard,
> when I've started clustering tests target then all of them failed because jbossweb.jar is missing. Could you modify our ant scripts to download it and put to classpath when for "tests" target, please.
> Thank you,
> Mirek

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 07:21:23 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Mon, 4 Jul 2011 07:21:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMESSAGING-1883) Server side
 failover may cause ClientConsumer.waitForOnMessageToComplete() to hang
In-Reply-To: <1557636092.33242.1309754723980.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1175796148.33567.1309778483755.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao resolved JBMESSAGING-1883.
---------------------------------------

    Resolution: Done


> Server side failover may cause ClientConsumer.waitForOnMessageToComplete() to hang
> ----------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1883
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1883
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP13, 1.4.8.SP1
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP14, 1.4.8.SP2
>
>
> When server side failover happens, the failover node will get "node left" notification from jgroups as well as "connection broken" notification from remoting on the connections through which message suckers are created. The listeners of the two notifications are executed concurrently and both try to close related resources. The "node left" listener performs failover for the dead node, where it closes all message suckers (underneath the ClientConsumers). The "connection broken" listener will close the related connection/session/consumer. If 
> 1. in failover the ClientConsumer.close() is called but before waitForOnMessageToComplete() is called, 
> 2. the session is being closed by the 'connection broken' listener.
> 3. when the waitForOnMessageToComplete() is called, it puts a 'Closer' task to executor and wait for it. However at that time the executor has been closed already in step 2. So the 'Closer' task will never get executed and it will wait forever.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 07:21:24 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Mon, 4 Jul 2011 07:21:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1883) Server side
 failover may cause ClientConsumer.waitForOnMessageToComplete() to hang
In-Reply-To: <1557636092.33242.1309754723980.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1651545768.33572.1309778484033.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao closed JBMESSAGING-1883.
-------------------------------------



> Server side failover may cause ClientConsumer.waitForOnMessageToComplete() to hang
> ----------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1883
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1883
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP13, 1.4.8.SP1
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP14, 1.4.8.SP2
>
>
> When server side failover happens, the failover node will get "node left" notification from jgroups as well as "connection broken" notification from remoting on the connections through which message suckers are created. The listeners of the two notifications are executed concurrently and both try to close related resources. The "node left" listener performs failover for the dead node, where it closes all message suckers (underneath the ClientConsumers). The "connection broken" listener will close the related connection/session/consumer. If 
> 1. in failover the ClientConsumer.close() is called but before waitForOnMessageToComplete() is called, 
> 2. the session is being closed by the 'connection broken' listener.
> 3. when the waitForOnMessageToComplete() is called, it puts a 'Closer' task to executor and wait for it. However at that time the executor has been closed already in step 2. So the 'Closer' task will never get executed and it will wait forever.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 07:50:23 2011
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Mon, 4 Jul 2011 07:50:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1181) CDI interceptors
	enabled randomly
Message-ID: <1943372077.33606.1309780223723.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

CDI interceptors enabled randomly
---------------------------------

                 Key: AS7-1181
                 URL: https://issues.jboss.org/browse/AS7-1181
             Project: Application Server 7
          Issue Type: Bug
          Components: CDI / Weld
    Affects Versions: 7.0.0.CR1
            Reporter: Jozef Hartinger
            Priority: Critical
             Fix For: 7.0.0.Final


A CDI interceptor does not seem to be enabled every time a CDI application is deployed.

To reproduce:
1.) Clone https://github.com/seam/compatibility/tree/arquillian-1.0.0.CR1
2.) Set JBOSS_HOME to point to JBoss AS 7 CR1 installation
3.) run mvn clean test -Darquillian=jbossas-managed-7 -Dtest=EnableInterceptorStressTest

The EnableInterceptorStressTest executes a simple interceptor testcase (EnableInterceptorTest) 20 times. Out of these 20 deployments, the test fails 6 - 13 times (the number varies randomly).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 09:07:23 2011
From: jira-events at lists.jboss.org (Fabian Lange (JIRA))
Date: Mon, 4 Jul 2011 09:07:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3116) Performance
 Regression due to mvel ParserContext now set,
 resulting in CompositeClassLoader loads
Message-ID: <2041340836.33655.1309784843699.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Performance Regression due to mvel ParserContext now set, resulting in CompositeClassLoader loads
-------------------------------------------------------------------------------------------------

                 Key: JBRULES-3116
                 URL: https://issues.jboss.org/browse/JBRULES-3116
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
    Affects Versions: 5.2.0.Final
            Reporter: Fabian Lange
            Assignee: Mark Proctor


I observed this issue already with 5.1, but now had time to verify it with 5.2.
Initial compilation time has exploded with those versions.

I have with the same test cases with 5.2 this:
org.drools.util.CompositeClassLoader$CachingLoader.load taking a total of 42 seconds
With 5.0 (where this Caching was not yet implemented)
I had a total time of less than 5 seconds spend in the ClassLoading.

The reason for this took me a while to find, but now I do have it:

org.mvel2.compiler.AbstractParser.createPropertyToken

is invoking hasImports() and getImport() on the ParseContext if not null.
Those in turn are invoking org.mvel2.ParserConfiguration.checkForDynamicImport
which invokes org.drools.util.CompositeClassLoader.loadClass

This is invoked on my table for expressions like this: "age >= 16"
So the org.drools.util.CompositeClassLoader$CachingLoader.load
will look for a class called "age" and a class called "16". Because the class not exists null/false are returned from the callchain.
However neither the CachingLoader, nor the Map in AbstractParser will cache the negative result. Causing this to happen for each row in my decisiontable.

And in 5.0 the whole part of the callgraph is not there.
I figured out, that in 5.0 versions, the AbstractParser never had a parse context in createPropertyToken

This might be because of the inconsistent usage of
    protected static ThreadLocal<ParserContext> parserContext;
    protected ParserContext pCtx;


So where does us leave this?
A possible easy solution would be to add the "negative" lookups to the CachingLoader.
However I would like to have doublechecked if the change in Abstract Parser was intentional and is now working correctly. Thus invoking the checkDynamicImports a lot is correct. Is it really the case that the parser needs to check for each literal this dynamic import thing? it obviously didnt do before.




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 09:09:23 2011
From: jira-events at lists.jboss.org (Fabian Lange (JIRA))
Date: Mon, 4 Jul 2011 09:09:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-3116) Performance
 Regression due to mvel ParserContext now set,
 resulting in CompositeClassLoader loads
In-Reply-To: <2041340836.33655.1309784843699.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1302464490.33660.1309784963878.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Fabian Lange updated JBRULES-3116:
----------------------------------

    Attachment: abstractParser-bug1.png


JProfiler Screenshot showing the Callchain.

> Performance Regression due to mvel ParserContext now set, resulting in CompositeClassLoader loads
> -------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3116
>                 URL: https://issues.jboss.org/browse/JBRULES-3116
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler
>    Affects Versions: 5.2.0.Final
>            Reporter: Fabian Lange
>            Assignee: Mark Proctor
>         Attachments: abstractParser-bug1.png
>
>
> I observed this issue already with 5.1, but now had time to verify it with 5.2.
> Initial compilation time has exploded with those versions.
> I have with the same test cases with 5.2 this:
> org.drools.util.CompositeClassLoader$CachingLoader.load taking a total of 42 seconds
> With 5.0 (where this Caching was not yet implemented)
> I had a total time of less than 5 seconds spend in the ClassLoading.
> The reason for this took me a while to find, but now I do have it:
> org.mvel2.compiler.AbstractParser.createPropertyToken
> is invoking hasImports() and getImport() on the ParseContext if not null.
> Those in turn are invoking org.mvel2.ParserConfiguration.checkForDynamicImport
> which invokes org.drools.util.CompositeClassLoader.loadClass
> This is invoked on my table for expressions like this: "age >= 16"
> So the org.drools.util.CompositeClassLoader$CachingLoader.load
> will look for a class called "age" and a class called "16". Because the class not exists null/false are returned from the callchain.
> However neither the CachingLoader, nor the Map in AbstractParser will cache the negative result. Causing this to happen for each row in my decisiontable.
> And in 5.0 the whole part of the callgraph is not there.
> I figured out, that in 5.0 versions, the AbstractParser never had a parse context in createPropertyToken
> This might be because of the inconsistent usage of
>     protected static ThreadLocal<ParserContext> parserContext;
>     protected ParserContext pCtx;
> So where does us leave this?
> A possible easy solution would be to add the "negative" lookups to the CachingLoader.
> However I would like to have doublechecked if the change in Abstract Parser was intentional and is now working correctly. Thus invoking the checkDynamicImports a lot is correct. Is it really the case that the parser needs to check for each literal this dynamic import thing? it obviously didnt do before.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 09:14:23 2011
From: jira-events at lists.jboss.org (Fabian Lange (JIRA))
Date: Mon, 4 Jul 2011 09:14:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-3116) Performance
 Regression due to mvel ParserContext now set,
 resulting in CompositeClassLoader loads
In-Reply-To: <2041340836.33655.1309784843699.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <536075820.33663.1309785263665.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Fabian Lange updated JBRULES-3116:
----------------------------------

    Description: 
I observed this issue already with 5.1, but now had time to verify it with 5.2.
Initial compilation time has exploded with those versions.

I have with the same test cases with 5.2 this:
{{org.drools.util.CompositeClassLoader$CachingLoader.load}} taking a total of 42 seconds
With 5.0 (where this Caching was not yet implemented)
I had a total time of less than 5 seconds spend in the ClassLoading.

The reason for this took me a while to find, but now I do have it:
{{org.mvel2.compiler.AbstractParser.createPropertyToken}}

is invoking {{hasImports()}} and {{getImport()}} on the ParseContext if not null:
see:
https://github.com/mikebrock/mvel/blob/master/src/main/java/org/mvel2/compiler/AbstractParser.java#L1292

Those in turn are invoking {{org.mvel2.ParserConfiguration.checkForDynamicImport}}
which invokes {{org.drools.util.CompositeClassLoader.loadClass}}

This is invoked on my table for expressions like this: "{{age >= 16}}"
So the {{org.drools.util.CompositeClassLoader$CachingLoader.load}}
will look for a class called "age" and a class called "16". Because the class not exists null/false are returned from the callchain.
However neither the {{CachingLoader}}, nor the Map in {{AbstractParser}} will cache the negative result. Causing this to happen for each row in my decisiontable.

And in 5.0 the whole part of the callgraph is not there.
I figured out, that in 5.0 versions, the {{AbstractParser}} never had a parse context in createPropertyToken

This might be because of the inconsistent usage of
{code}
protected static ThreadLocal<ParserContext> parserContext;
protected ParserContext pCtx;
{code}

So where does us leave this?
A possible easy solution would be to add the "negative" lookups to the CachingLoader.
However I would like to have doublechecked if the change in Abstract Parser was intentional and is now working correctly. Thus invoking the checkDynamicImports a lot is correct. Is it really the case that the parser needs to check for each literal this dynamic import thing? it obviously didnt do before.




  was:
I observed this issue already with 5.1, but now had time to verify it with 5.2.
Initial compilation time has exploded with those versions.

I have with the same test cases with 5.2 this:
org.drools.util.CompositeClassLoader$CachingLoader.load taking a total of 42 seconds
With 5.0 (where this Caching was not yet implemented)
I had a total time of less than 5 seconds spend in the ClassLoading.

The reason for this took me a while to find, but now I do have it:

org.mvel2.compiler.AbstractParser.createPropertyToken

is invoking hasImports() and getImport() on the ParseContext if not null.
Those in turn are invoking org.mvel2.ParserConfiguration.checkForDynamicImport
which invokes org.drools.util.CompositeClassLoader.loadClass

This is invoked on my table for expressions like this: "age >= 16"
So the org.drools.util.CompositeClassLoader$CachingLoader.load
will look for a class called "age" and a class called "16". Because the class not exists null/false are returned from the callchain.
However neither the CachingLoader, nor the Map in AbstractParser will cache the negative result. Causing this to happen for each row in my decisiontable.

And in 5.0 the whole part of the callgraph is not there.
I figured out, that in 5.0 versions, the AbstractParser never had a parse context in createPropertyToken

This might be because of the inconsistent usage of
    protected static ThreadLocal<ParserContext> parserContext;
    protected ParserContext pCtx;


So where does us leave this?
A possible easy solution would be to add the "negative" lookups to the CachingLoader.
However I would like to have doublechecked if the change in Abstract Parser was intentional and is now working correctly. Thus invoking the checkDynamicImports a lot is correct. Is it really the case that the parser needs to check for each literal this dynamic import thing? it obviously didnt do before.






> Performance Regression due to mvel ParserContext now set, resulting in CompositeClassLoader loads
> -------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3116
>                 URL: https://issues.jboss.org/browse/JBRULES-3116
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler
>    Affects Versions: 5.2.0.Final
>            Reporter: Fabian Lange
>            Assignee: Mark Proctor
>         Attachments: abstractParser-bug1.png
>
>
> I observed this issue already with 5.1, but now had time to verify it with 5.2.
> Initial compilation time has exploded with those versions.
> I have with the same test cases with 5.2 this:
> {{org.drools.util.CompositeClassLoader$CachingLoader.load}} taking a total of 42 seconds
> With 5.0 (where this Caching was not yet implemented)
> I had a total time of less than 5 seconds spend in the ClassLoading.
> The reason for this took me a while to find, but now I do have it:
> {{org.mvel2.compiler.AbstractParser.createPropertyToken}}
> is invoking {{hasImports()}} and {{getImport()}} on the ParseContext if not null:
> see:
> https://github.com/mikebrock/mvel/blob/master/src/main/java/org/mvel2/compiler/AbstractParser.java#L1292
> Those in turn are invoking {{org.mvel2.ParserConfiguration.checkForDynamicImport}}
> which invokes {{org.drools.util.CompositeClassLoader.loadClass}}
> This is invoked on my table for expressions like this: "{{age >= 16}}"
> So the {{org.drools.util.CompositeClassLoader$CachingLoader.load}}
> will look for a class called "age" and a class called "16". Because the class not exists null/false are returned from the callchain.
> However neither the {{CachingLoader}}, nor the Map in {{AbstractParser}} will cache the negative result. Causing this to happen for each row in my decisiontable.
> And in 5.0 the whole part of the callgraph is not there.
> I figured out, that in 5.0 versions, the {{AbstractParser}} never had a parse context in createPropertyToken
> This might be because of the inconsistent usage of
> {code}
> protected static ThreadLocal<ParserContext> parserContext;
> protected ParserContext pCtx;
> {code}
> So where does us leave this?
> A possible easy solution would be to add the "negative" lookups to the CachingLoader.
> However I would like to have doublechecked if the change in Abstract Parser was intentional and is now working correctly. Thus invoking the checkDynamicImports a lot is correct. Is it really the case that the parser needs to check for each literal this dynamic import thing? it obviously didnt do before.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 09:25:25 2011
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 4 Jul 2011 09:25:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-933) Commands to create
 and remove datasources
In-Reply-To: <1839750753.39764.1306929421203.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <385792916.33679.1309785925174.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Alexey Loubyansky resolved AS7-933.
-----------------------------------

    Fix Version/s: 7.0.0.CR1
                       (was: 7.1.0.Alpha1)
       Resolution: Done


This was done for 7.0.0.CR1, actually.

> Commands to create and remove datasources
> -----------------------------------------
>
>                 Key: AS7-933
>                 URL: https://issues.jboss.org/browse/AS7-933
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: CLI
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 7.0.0.CR1
>
>
> Commands to create and delete datasources.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 10:15:24 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Mon, 4 Jul 2011 10:15:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1182)
 DatabaseServerLoginModule doesn't work
Message-ID: <320201656.33784.1309788924180.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

DatabaseServerLoginModule doesn't work
--------------------------------------

                 Key: AS7-1182
                 URL: https://issues.jboss.org/browse/AS7-1182
             Project: Application Server 7
          Issue Type: Bug
          Components: Security
    Affects Versions: 7.0.0.CR1
            Reporter: Juergen Zimmermann


I want to migrate from JBossAS 6 to 7.0.0.CR1. In standalone.xml I declare the following security domain, but get the stacktrace (see below) looking for UsersRolesLoginModule instead of DatabaseServerLoginModule.

Security domain in standalone.xml:
   <security-domain name="swe2" cache-type="default">
      <authentication>
         <login-module code="Database" flag="required">
            <module-option name="dsJndiName" value="java:/swe2DS"/>
            <module-option name="unauthenticatedIdentity" value="gast"/>
            <module-option name="principalsQuery" value="SELECT password FROM kunde WHERE username=?"/>
            <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM swe2_role r INNER JOIN kunde k ON r.kunde_fk = k.k_id WHERE k.username=?"/>
            <module-option name="hashAlgorithm" value="SHA-1"/>
            <module-option name="hashEncoding" value="base64"/>
         </login-module>
      </authentication>
   </security-domain>

Stacktrace regarding UsersRolesLoginModule (instead of DatabaseServerLoginModule):
16:03:58,528 ERROR [org.jboss.security.auth.spi.UsersRolesLoginModule] (http--127.0.0.1-8080-2) Failed to load users/passwords/role files: java.io.IOException: No properties file: users.properties or defaults: defaultUsers.properties found
	at org.jboss.security.auth.spi.Util.loadProperties(Util.java:227) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
	at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:188) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
	at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:202) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
	at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:129) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
	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 javax.security.auth.login.LoginContext.invoke(LoginContext.java:756) [:1.6.0_26]
	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) [:1.6.0_26]
	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683) [:1.6.0_26]
	at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_26]
	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) [:1.6.0_26]
	at javax.security.auth.login.LoginContext.login(LoginContext.java:579) [:1.6.0_26]
	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:411) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:154) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
	at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:127) [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
	at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:180) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:446) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.0.0.CR1.jar:7.0.0.CR1]
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
	at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 12:12:23 2011
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Mon, 4 Jul 2011 12:12:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3117) Compiling two
	functions fails
Message-ID: <665397500.34034.1309795943618.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Compiling two functions fails 
------------------------------

                 Key: JBRULES-3117
                 URL: https://issues.jboss.org/browse/JBRULES-3117
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler (expert)
    Affects Versions: 5.2.0.Final
            Reporter: Wolfgang Laun
            Assignee: Mark Proctor
            Priority: Blocker
             Fix For: 5.2.1.Final


Compiling these two function together fails:

function boolean isOutOfRange( Object value, int lower ){
    return true;
}
function boolean isNotContainedInt( Object object, int[] values ){
    return true;
}

[ isNotContainedInt : unable to resolve type while building function ]

If the first one is removed, or its arguments are reduced, the remainder compiles.



--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 12:14:23 2011
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Mon, 4 Jul 2011 12:14:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-3117) Compiling two
	functions fails
In-Reply-To: <665397500.34034.1309795943618.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <587684134.34040.1309796063742.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Mark Proctor reassigned JBRULES-3117:
-------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)


> Compiling two functions fails 
> ------------------------------
>
>                 Key: JBRULES-3117
>                 URL: https://issues.jboss.org/browse/JBRULES-3117
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler (expert)
>    Affects Versions: 5.2.0.Final
>            Reporter: Wolfgang Laun
>            Assignee: Edson Tirelli
>            Priority: Blocker
>             Fix For: 5.2.1.Final
>
>
> Compiling these two function together fails:
> function boolean isOutOfRange( Object value, int lower ){
>     return true;
> }
> function boolean isNotContainedInt( Object object, int[] values ){
>     return true;
> }
> [ isNotContainedInt : unable to resolve type while building function ]
> If the first one is removed, or its arguments are reduced, the remainder compiles.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 14:12:23 2011
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Mon, 4 Jul 2011 14:12:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-682)
 http://repository.jboss.org/maven2/ serving HTTP 403 to hosts outside
 RedHat VPN
In-Reply-To: <1378297995.38124.1306874040969.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <178565184.34099.1309803143828.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Gier commented on JBBUILD-682:
-----------------------------------

Can you point me to some upstream jira or attach some build log information that shows the difference you see between what happens with 404 vs. 403?  From my previous testing, Maven handles 403 correctly, and it wouldn't make any difference to change the error to 404.  What version of Maven are you using?

> http://repository.jboss.org/maven2/ serving HTTP 403 to hosts outside RedHat VPN
> --------------------------------------------------------------------------------
>
>                 Key: JBBUILD-682
>                 URL: https://issues.jboss.org/browse/JBBUILD-682
>             Project: JBoss Build System
>          Issue Type: Bug
>            Reporter: Marek Schmidt
>            Assignee: Paul Gier
>            Priority: Critical
>             Fix For: Build Support 2011
>
>
> The legacy maven repository http://repository.jboss.org/maven2/ is serving HTTP 403 to hosts outside RedHat VPN, causing lots of builds to fail.
> e.g. http://community.jboss.org/message/606819?tstart=0 with error:
> Access denied to: http://repository.jboss.org/maven2/trove/trove/2.1.1/trove-2.1.1.pom

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 15:36:23 2011
From: jira-events at lists.jboss.org (Savas Ali Tokmen (JIRA))
Date: Mon, 4 Jul 2011 15:36:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-682)
 http://repository.jboss.org/maven2/ serving HTTP 403 to hosts outside
 RedHat VPN
In-Reply-To: <1378297995.38124.1306874040969.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2076106683.34158.1309808183879.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Savas Ali Tokmen commented on JBBUILD-682:
------------------------------------------

Of course, with an error 403 you egt the following:

{noformat}
[ERROR] Failed to execute goal org.codehaus.cargo:cargo-maven2-plugin:1.1.1:undeploy (redeploy) on project helloservice:
        Execution redeploy of goal org.codehaus.cargo:cargo-maven2-plugin:1.1.1:undeploy failed:
        Plugin org.codehaus.cargo:cargo-maven2-plugin:1.1.1 or one of its dependencies could not be resolved:
        Failed to collect dependencies for org.codehaus.cargo:cargo-maven2-plugin:jar:1.1.1 ():
        Failed to read artifact descriptor for trove:trove:jar:2.1.1:
        Could not transfer artifact trove:trove:pom:2.1.1 from/to repository.jboss.org (http://repository.jboss.org/maven2/):
        Access denied to: http://repository.jboss.org/maven2/trove/trove/2.1.1/trove-2.1.1.pom -> [Help 1]
{noformat}

with an error 404, Maven cannot find on that repo and tries another one.

This is with Maven 3.0.3.

> http://repository.jboss.org/maven2/ serving HTTP 403 to hosts outside RedHat VPN
> --------------------------------------------------------------------------------
>
>                 Key: JBBUILD-682
>                 URL: https://issues.jboss.org/browse/JBBUILD-682
>             Project: JBoss Build System
>          Issue Type: Bug
>            Reporter: Marek Schmidt
>            Assignee: Paul Gier
>            Priority: Critical
>             Fix For: Build Support 2011
>
>
> The legacy maven repository http://repository.jboss.org/maven2/ is serving HTTP 403 to hosts outside RedHat VPN, causing lots of builds to fail.
> e.g. http://community.jboss.org/message/606819?tstart=0 with error:
> Access denied to: http://repository.jboss.org/maven2/trove/trove/2.1.1/trove-2.1.1.pom

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 15:45:23 2011
From: jira-events at lists.jboss.org (Michael Anstis (JIRA))
Date: Mon, 4 Jul 2011 15:45:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3118) Parser: import of
 class called Enum fails to parse
Message-ID: <601618379.34171.1309808723828.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Parser: import of class called Enum fails to parse
--------------------------------------------------

                 Key: JBRULES-3118
                 URL: https://issues.jboss.org/browse/JBRULES-3118
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.2.0.Final
            Reporter: Michael Anstis
            Assignee: Mark Proctor


The following DRL fails to compile, with error "Syntax error on token "enum", Identifier expected."

package com.sample
 
import com.sample.DroolsTest.Message;

//The "enum" sub-package causes the problem, not "Enum" class
import org.apache.commons.lang.enum.Enum

rule "Hello World"
    when
        m : Message( status == Message.HELLO, myMessage : message )
    then
        System.out.println( myMessage );
        m.setMessage( "Goodbye cruel world" );
        m.setStatus( Message.GOODBYE );
        update( m );
end

rule "GoodBye"
    when
        Message( status == Message.GOODBYE, myMessage : message )
    then
        System.out.println( myMessage );
end


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 15:54:23 2011
From: jira-events at lists.jboss.org (Michael Anstis (JIRA))
Date: Mon, 4 Jul 2011 15:54:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-3118) Parser: import of
 class with "enum" in the FQN fails to parse
In-Reply-To: <601618379.34171.1309808723828.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1563281412.34179.1309809263661.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Michael Anstis updated JBRULES-3118:
------------------------------------

    Summary: Parser: import of class with "enum" in the FQN fails to parse  (was: Parser: import of class called Enum fails to parse)


> Parser: import of class with "enum" in the FQN fails to parse
> -------------------------------------------------------------
>
>                 Key: JBRULES-3118
>                 URL: https://issues.jboss.org/browse/JBRULES-3118
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.2.0.Final
>            Reporter: Michael Anstis
>            Assignee: Mark Proctor
>
> The following DRL fails to compile, with error "Syntax error on token "enum", Identifier expected."
> package com.sample
>  
> import com.sample.DroolsTest.Message;
> //The "enum" sub-package causes the problem, not "Enum" class
> import org.apache.commons.lang.enum.Enum
> rule "Hello World"
>     when
>         m : Message( status == Message.HELLO, myMessage : message )
>     then
>         System.out.println( myMessage );
>         m.setMessage( "Goodbye cruel world" );
>         m.setStatus( Message.GOODBYE );
>         update( m );
> end
> rule "GoodBye"
>     when
>         Message( status == Message.GOODBYE, myMessage : message )
>     then
>         System.out.println( myMessage );
> end

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 18:48:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 4 Jul 2011 18:48:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1181) CDI interceptors
 enabled randomly
In-Reply-To: <1943372077.33606.1309780223723.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1788084192.34203.1309819703646.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas commented on AS7-1181:
-------------------------------------

This will require a weld release to fix

> CDI interceptors enabled randomly
> ---------------------------------
>
>                 Key: AS7-1181
>                 URL: https://issues.jboss.org/browse/AS7-1181
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 7.0.0.CR1
>            Reporter: Jozef Hartinger
>            Priority: Critical
>             Fix For: 7.0.0.Final
>
>
> A CDI interceptor does not seem to be enabled every time a CDI application is deployed.
> To reproduce:
> 1.) Clone https://github.com/seam/compatibility/tree/arquillian-1.0.0.CR1
> 2.) Set JBOSS_HOME to point to JBoss AS 7 CR1 installation
> 3.) run mvn clean test -Darquillian=jbossas-managed-7 -Dtest=EnableInterceptorStressTest
> The EnableInterceptorStressTest executes a simple interceptor testcase (EnableInterceptorTest) 20 times. Out of these 20 deployments, the test fails 6 - 13 times (the number varies randomly).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 19:08:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 4 Jul 2011 19:08:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1183) Class-Path entries in
 ear/lib that point outside the deployment create module dependencies
Message-ID: <275505591.34222.1309820903621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Class-Path entries in ear/lib that point outside the deployment create module dependencies
------------------------------------------------------------------------------------------

                 Key: AS7-1183
                 URL: https://issues.jboss.org/browse/AS7-1183
             Project: Application Server 7
          Issue Type: Bug
    Affects Versions: 7.0.0.CR1
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas
             Fix For: 7.0.0.Final


This means that a third party jar can prevent a deployment from completing, and is not consistent with other Class-Path handling.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 19:49:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 4 Jul 2011 19:49:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1183) Class-Path entries
 in ear/lib that point outside the deployment create module dependencies
In-Reply-To: <275505591.34222.1309820903621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1245272907.34231.1309823363652.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved AS7-1183.
---------------------------------

    Resolution: Done


> Class-Path entries in ear/lib that point outside the deployment create module dependencies
> ------------------------------------------------------------------------------------------
>
>                 Key: AS7-1183
>                 URL: https://issues.jboss.org/browse/AS7-1183
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.CR1
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 7.0.0.Final
>
>
> This means that a third party jar can prevent a deployment from completing, and is not consistent with other Class-Path handling.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 22:44:23 2011
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Mon, 4 Jul 2011 22:44:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1181) CDI interceptors
	enabled randomly
In-Reply-To: <1943372077.33606.1309780223723.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2051145497.34415.1309833863621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jason Greene updated AS7-1181:
------------------------------

    Priority: Blocker  (was: Critical)


> CDI interceptors enabled randomly
> ---------------------------------
>
>                 Key: AS7-1181
>                 URL: https://issues.jboss.org/browse/AS7-1181
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 7.0.0.CR1
>            Reporter: Jozef Hartinger
>            Priority: Blocker
>             Fix For: 7.0.0.Final
>
>
> A CDI interceptor does not seem to be enabled every time a CDI application is deployed.
> To reproduce:
> 1.) Clone https://github.com/seam/compatibility/tree/arquillian-1.0.0.CR1
> 2.) Set JBOSS_HOME to point to JBoss AS 7 CR1 installation
> 3.) run mvn clean test -Darquillian=jbossas-managed-7 -Dtest=EnableInterceptorStressTest
> The EnableInterceptorStressTest executes a simple interceptor testcase (EnableInterceptorTest) 20 times. Out of these 20 deployments, the test fails 6 - 13 times (the number varies randomly).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 23:43:23 2011
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Mon, 4 Jul 2011 23:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1166) Quit the CLI on EOF
In-Reply-To: <115625773.31875.1309517243776.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <149655686.34534.1309837403682.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jason Greene reassigned AS7-1166:
---------------------------------

    Assignee: Alexey Loubyansky


> Quit the CLI on EOF
> -------------------
>
>                 Key: AS7-1166
>                 URL: https://issues.jboss.org/browse/AS7-1166
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: CLI
>    Affects Versions: 7.1.0.Alpha1
>            Reporter: Marek Schmidt
>            Assignee: Alexey Loubyansky
>
> jboss-admin.sh should behave more like a shell and terminate on EOF (ctrl-D)
> The current behavior is quite counter-intuitive and trying to do e.g.
> echo "deploy foo.war" | ./jboss-admin.sh --connect 
> leads the CLI into an infinite-loop generating infinite number of prompts.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 23:43:23 2011
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Mon, 4 Jul 2011 23:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1166) Quit the CLI on EOF
In-Reply-To: <115625773.31875.1309517243776.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <545185048.34538.1309837403797.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jason Greene updated AS7-1166:
------------------------------

    Affects Version/s: 7.1.0.Alpha1
                           (was: 7.0.0.CR1)


> Quit the CLI on EOF
> -------------------
>
>                 Key: AS7-1166
>                 URL: https://issues.jboss.org/browse/AS7-1166
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: CLI
>    Affects Versions: 7.1.0.Alpha1
>            Reporter: Marek Schmidt
>            Assignee: Alexey Loubyansky
>
> jboss-admin.sh should behave more like a shell and terminate on EOF (ctrl-D)
> The current behavior is quite counter-intuitive and trying to do e.g.
> echo "deploy foo.war" | ./jboss-admin.sh --connect 
> leads the CLI into an infinite-loop generating infinite number of prompts.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 23:47:24 2011
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Mon, 4 Jul 2011 23:47:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1172) JNDI
In-Reply-To: <553584792.32548.1309538363672.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1183522360.34559.1309837644377.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jason Greene reassigned AS7-1172:
---------------------------------

    Assignee: John Bailey


> JNDI 
> -----
>
>                 Key: AS7-1172
>                 URL: https://issues.jboss.org/browse/AS7-1172
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Naming
>    Affects Versions: 7.0.0.CR1
>            Reporter: Alexandre Gattiker
>            Assignee: John Bailey
>             Fix For: 7.0.1.Final
>
>
> If a JMS destination is created with a JNDI name starting with "/jms/", the JNDI View issues an error message. The destination appears to be up and running fine though.
> <h1>java: Namespace</h1>
> <pre>
>   +- topic (class: javax.naming.Context)
>   |   +- test (class: org.jboss.as.naming.context.ModularReference)
>   +- app (class: javax.naming.Reference)
>   +- module (class: javax.naming.Reference)
>   +- comp (class: javax.naming.Reference)
>   +- queue (class: javax.naming.Context)
>   |   +- test (class: org.jboss.as.naming.context.ModularReference)
>   +- jms (class: javax.naming.Context)
> Failed to lookup: jms, errmsg=Name 'jms' not found in context ''
>   +- global (class: javax.naming.Reference)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul  4 23:47:24 2011
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Mon, 4 Jul 2011 23:47:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1172) JNDI
In-Reply-To: <553584792.32548.1309538363672.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <613243885.34562.1309837644522.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jason Greene updated AS7-1172:
------------------------------

    Fix Version/s: 7.0.1.Final


This is because the jndiview tool was never updated to support our multi-namespace contexts

> JNDI 
> -----
>
>                 Key: AS7-1172
>                 URL: https://issues.jboss.org/browse/AS7-1172
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Naming
>    Affects Versions: 7.0.0.CR1
>            Reporter: Alexandre Gattiker
>            Assignee: John Bailey
>             Fix For: 7.0.1.Final
>
>
> If a JMS destination is created with a JNDI name starting with "/jms/", the JNDI View issues an error message. The destination appears to be up and running fine though.
> <h1>java: Namespace</h1>
> <pre>
>   +- topic (class: javax.naming.Context)
>   |   +- test (class: org.jboss.as.naming.context.ModularReference)
>   +- app (class: javax.naming.Reference)
>   +- module (class: javax.naming.Reference)
>   +- comp (class: javax.naming.Reference)
>   +- queue (class: javax.naming.Context)
>   |   +- test (class: org.jboss.as.naming.context.ModularReference)
>   +- jms (class: javax.naming.Context)
> Failed to lookup: jms, errmsg=Name 'jms' not found in context ''
>   +- global (class: javax.naming.Reference)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 03:09:23 2011
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Tue, 5 Jul 2011 03:09:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3119) Timestamp and
 Duration no longer work with complex expressions
Message-ID: <1482110319.34834.1309849763630.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Timestamp and Duration no longer work with complex expressions
--------------------------------------------------------------

                 Key: JBRULES-3119
                 URL: https://issues.jboss.org/browse/JBRULES-3119
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Mark Proctor
            Assignee: Mark Proctor


They needed to be updated to use the MVEL reader method, so they can work on things beyond direct accessors.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 03:12:23 2011
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Tue, 5 Jul 2011 03:12:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-3119) Timestamp and
 Duration no longer work with complex expressions
In-Reply-To: <1482110319.34834.1309849763630.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1388680442.34837.1309849943630.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Mark Proctor resolved JBRULES-3119.
-----------------------------------

    Fix Version/s: 5.3.0.Beta1
       Resolution: Done


> Timestamp and Duration no longer work with complex expressions
> --------------------------------------------------------------
>
>                 Key: JBRULES-3119
>                 URL: https://issues.jboss.org/browse/JBRULES-3119
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 5.3.0.Beta1
>
>
> They needed to be updated to use the MVEL reader method, so they can work on things beyond direct accessors.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 03:14:23 2011
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Tue, 5 Jul 2011 03:14:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-3119) Timestamp and
 Duration no longer work with complex expressions
In-Reply-To: <1482110319.34834.1309849763630.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1691115213.34842.1309850063703.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Mark Proctor closed JBRULES-3119.
---------------------------------



> Timestamp and Duration no longer work with complex expressions
> --------------------------------------------------------------
>
>                 Key: JBRULES-3119
>                 URL: https://issues.jboss.org/browse/JBRULES-3119
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 5.3.0.Beta1
>
>
> They needed to be updated to use the MVEL reader method, so they can work on things beyond direct accessors.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 03:14:23 2011
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Tue, 5 Jul 2011 03:14:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3119) Timestamp and
 Duration no longer work with complex expressions
In-Reply-To: <1482110319.34834.1309849763630.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <70797592.34841.1309850063680.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Mark Proctor commented on JBRULES-3119:
---------------------------------------

This is fixed in master, not yet cherry picked to 5.2.x
commit 64f3ba9f2cbd12ff4d9b5c932cf38690041e9971
Author: Mark Proctor <mdproctor at gmail.com>
Date:   Tue Jul 5 08:10:51 2011 +0100

    JBRULES-3119 Timestamp and Duration no longer work with complex expressions


> Timestamp and Duration no longer work with complex expressions
> --------------------------------------------------------------
>
>                 Key: JBRULES-3119
>                 URL: https://issues.jboss.org/browse/JBRULES-3119
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For: 5.3.0.Beta1
>
>
> They needed to be updated to use the MVEL reader method, so they can work on things beyond direct accessors.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 03:16:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 5 Jul 2011 03:16:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1184) Resteasy-jaxrs module
 is missing log4j dependency
Message-ID: <84542111.34847.1309850183743.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Resteasy-jaxrs module is missing log4j dependency
-------------------------------------------------

                 Key: AS7-1184
                 URL: https://issues.jboss.org/browse/AS7-1184
             Project: Application Server 7
          Issue Type: Bug
    Affects Versions: 7.0.0.CR1
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas
             Fix For: 7.0.0.Final




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 03:30:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 5 Jul 2011 03:30:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1184) Resteasy-jaxrs
 module is missing log4j dependency
In-Reply-To: <84542111.34847.1309850183743.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1430261071.34868.1309851023638.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved AS7-1184.
---------------------------------

    Resolution: Done


> Resteasy-jaxrs module is missing log4j dependency
> -------------------------------------------------
>
>                 Key: AS7-1184
>                 URL: https://issues.jboss.org/browse/AS7-1184
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.CR1
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 7.0.0.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 03:36:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Tue, 5 Jul 2011 03:36:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1185) Classpath issue break
 localization in Hibernate Validator
Message-ID: <1248663250.34872.1309851383660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Classpath issue break localization in Hibernate Validator
---------------------------------------------------------

                 Key: AS7-1185
                 URL: https://issues.jboss.org/browse/AS7-1185
             Project: Application Server 7
          Issue Type: Bug
          Components: Modules
    Affects Versions: 7.0.0.CR1
            Reporter: Juergen Zimmermann


If you want Hibernate Validator to produce internationalized / localized messages you need properties files like e.g. ValidatorMessages_en.properties or ValidatorMessages_de.properties. These properties files must be in the Classpath. Thus if you need them in an EJB module, they are placed in the root directory of the EAR.

According to the language the right file is picked up, and the right hand side has the localized message belonging to the key on the left hand side. However, if no key is found or if the properties file isn't found, then the localized message is just "{key}" aka the template message.

I'll attach a testcase to reproduce this issue that ValidatorMessage_xx.properties isn't found in the Classpath.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 03:36:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Tue, 5 Jul 2011 03:36:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1185) Classpath issue
 breaks localization in Hibernate Validator
In-Reply-To: <1248663250.34872.1309851383660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <458523276.34874.1309851383702.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Juergen Zimmermann updated AS7-1185:
------------------------------------

    Summary: Classpath issue breaks localization in Hibernate Validator  (was: Classpath issue break localization in Hibernate Validator)


> Classpath issue breaks localization in Hibernate Validator
> ----------------------------------------------------------
>
>                 Key: AS7-1185
>                 URL: https://issues.jboss.org/browse/AS7-1185
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Modules
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>
> If you want Hibernate Validator to produce internationalized / localized messages you need properties files like e.g. ValidatorMessages_en.properties or ValidatorMessages_de.properties. These properties files must be in the Classpath. Thus if you need them in an EJB module, they are placed in the root directory of the EAR.
> According to the language the right file is picked up, and the right hand side has the localized message belonging to the key on the left hand side. However, if no key is found or if the properties file isn't found, then the localized message is just "{key}" aka the template message.
> I'll attach a testcase to reproduce this issue that ValidatorMessage_xx.properties isn't found in the Classpath.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 03:38:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Tue, 5 Jul 2011 03:38:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1185) Classpath issue
 breaks localization in Hibernate Validator
In-Reply-To: <1248663250.34872.1309851383660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2107505758.34880.1309851503744.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Juergen Zimmermann updated AS7-1185:
------------------------------------

    Attachment: testcase.ear
                testcase-src.zip


> Classpath issue breaks localization in Hibernate Validator
> ----------------------------------------------------------
>
>                 Key: AS7-1185
>                 URL: https://issues.jboss.org/browse/AS7-1185
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Modules
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>         Attachments: testcase-src.zip, testcase.ear
>
>
> If you want Hibernate Validator to produce internationalized / localized messages you need properties files like e.g. ValidatorMessages_en.properties or ValidatorMessages_de.properties. These properties files must be in the Classpath. Thus if you need them in an EJB module, they are placed in the root directory of the EAR.
> According to the language the right file is picked up, and the right hand side has the localized message belonging to the key on the left hand side. However, if no key is found or if the properties file isn't found, then the localized message is just "{key}" aka the template message.
> I'll attach a testcase to reproduce this issue that ValidatorMessage_xx.properties isn't found in the Classpath.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 03:40:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Tue, 5 Jul 2011 03:40:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1185) Classpath issue
 breaks localization in Hibernate Validator
In-Reply-To: <1248663250.34872.1309851383660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <838246426.34885.1309851623733.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Juergen Zimmermann commented on AS7-1185:
-----------------------------------------

You can invoke the testcase as a RESTful webservice via a POST request, and just submit this XML data so that the <name> content is invalid:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<customer id="1">
<name>Name_1</name>
</customer>

> Classpath issue breaks localization in Hibernate Validator
> ----------------------------------------------------------
>
>                 Key: AS7-1185
>                 URL: https://issues.jboss.org/browse/AS7-1185
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Modules
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>         Attachments: testcase-src.zip, testcase.ear
>
>
> If you want Hibernate Validator to produce internationalized / localized messages you need properties files like e.g. ValidatorMessages_en.properties or ValidatorMessages_de.properties. These properties files must be in the Classpath. Thus if you need them in an EJB module, they are placed in the root directory of the EAR.
> According to the language the right file is picked up, and the right hand side has the localized message belonging to the key on the left hand side. However, if no key is found or if the properties file isn't found, then the localized message is just "{key}" aka the template message.
> I'll attach a testcase to reproduce this issue that ValidatorMessage_xx.properties isn't found in the Classpath.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 04:09:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 5 Jul 2011 04:09:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-2260) Fix maven
 warning 'The expression ${artifactId} is deprecated.'
Message-ID: <178534740.34916.1309853363748.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Fix maven warning 'The expression ${artifactId} is deprecated.'
---------------------------------------------------------------

                 Key: EJBTHREE-2260
                 URL: https://issues.jboss.org/browse/EJBTHREE-2260
             Project: EJB 3.0
          Issue Type: Task
            Reporter: Carlo de Wolf
            Assignee: Carlo de Wolf
            Priority: Minor
             Fix For: 2.0.0-beta-2


{noformat}
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for org.jboss.ejb3:jboss-ejb3-cache:jar:2.0.0-beta-2-SNAPSHOT
[WARNING] The expression ${artifactId} is deprecated. Please use ${project.artifactId} instead.
[WARNING] 
{noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 04:13:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 5 Jul 2011 04:13:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-2260) Fix maven
 warning 'The expression ${artifactId} is deprecated.'
In-Reply-To: <178534740.34916.1309853363748.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <857268947.34919.1309853603620.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf resolved EJBTHREE-2260.
-------------------------------------

    Resolution: Done


> Fix maven warning 'The expression ${artifactId} is deprecated.'
> ---------------------------------------------------------------
>
>                 Key: EJBTHREE-2260
>                 URL: https://issues.jboss.org/browse/EJBTHREE-2260
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>            Priority: Minor
>             Fix For: 2.0.0-beta-2
>
>
> {noformat}
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model for org.jboss.ejb3:jboss-ejb3-cache:jar:2.0.0-beta-2-SNAPSHOT
> [WARNING] The expression ${artifactId} is deprecated. Please use ${project.artifactId} instead.
> [WARNING] 
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 04:38:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Tue, 5 Jul 2011 04:38:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1186) EJB interceptor not
	invoked
Message-ID: <727231980.34928.1309855103614.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

EJB interceptor not invoked
---------------------------

                 Key: AS7-1186
                 URL: https://issues.jboss.org/browse/AS7-1186
             Project: Application Server 7
          Issue Type: Bug
          Components: EJB
            Reporter: Juergen Zimmermann


I'll provide a testcase showing that an EJB 3 interceptor is not invoked although defined in MEAT-INF/ejb-jar.xml.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 04:40:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Tue, 5 Jul 2011 04:40:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1186) EJB interceptor not
	invoked
In-Reply-To: <727231980.34928.1309855103614.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1466187332.34931.1309855223636.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Juergen Zimmermann updated AS7-1186:
------------------------------------

    Attachment: testcase-src.zip
                testcase.ear


The testcase is a RESTful web service. Just submit a GET request, e.g. the URL http://localhost:8080/testcase/customermanagement/customer/1 in a web browser. You won't see the output as implemented in the MyInterceptor class.

> EJB interceptor not invoked
> ---------------------------
>
>                 Key: AS7-1186
>                 URL: https://issues.jboss.org/browse/AS7-1186
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Juergen Zimmermann
>         Attachments: testcase-src.zip, testcase.ear
>
>
> I'll provide a testcase showing that an EJB 3 interceptor is not invoked although defined in MEAT-INF/ejb-jar.xml.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 05:53:23 2011
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Tue, 5 Jul 2011 05:53:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-205) Invalid async
 context for servlet: Atmosphere Async Servlet on JBoss Web
In-Reply-To: <1369266963.32802.1309619303616.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <689521807.35050.1309859603799.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Remy Maucherat commented on JBWEB-205:
--------------------------------------

I have verified that the listener events are correctly called (especially the onComplete event). Despite this, each async processing spawns two threads:
- Atmosphere-AsyncWrite-0
- Atmosphere-BroadcasterConfig-0
The first one goes away if the client disconnects. Helping hide the issue is that all threads have the same name.

Another issue: until some connection to the counter occurs, HornetQ spawns one thread per counter "tick".

> Invalid async context for servlet: Atmosphere Async  Servlet on JBoss Web
> -------------------------------------------------------------------------
>
>                 Key: JBWEB-205
>                 URL: https://issues.jboss.org/browse/JBWEB-205
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-7.0.0.CR1
>         Environment: Firefox 4.0.1 / Chromium 12 
> AS 6.0.0.Final / 6.1.0-SNAPSHOT / AS 7.0.0.CR1 
> Atmosphere 0.7.1/0.7.2 
>            Reporter: Luk?? Fry?
>            Assignee: Remy Maucherat
>            Priority: Critical
>         Attachments: push-jms.war
>
>
> Source of sample for reproduction:
> https://github.com/lfryc/push-jms/commit/9cee160570e049ca4783e1fcbdac25ffef1b10b7
> {code}
> 16:08:28,467 ERROR [org.apache.catalina.connector.CoyoteAdapter] (http-localhost-127.0.0.1-8080-7) An exception or error occurred in the container during the request processing: java.lang.IllegalStateException: Invalid async context for servlet AutoRegisteredPushServlet
> 	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:643) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:402) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:183) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:246) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:128) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:265) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11Processor.event(Http11Processor.java:757) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.event(Http11Protocol.java:615) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:938) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at java.lang.Thread.run(Thread.java:636) [:1.6.0_20]
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Tue Jul  5 05:59:23 2011
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Tue, 5 Jul 2011 05:59:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBWEB-205) Invalid async
 context for servlet: Atmosphere Async Servlet on JBoss Web
In-Reply-To: <1369266963.32802.1309619303616.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <167414285.35054.1309859963654.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Remy Maucherat resolved JBWEB-205.
----------------------------------

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


I believe I have properly filtered the extra events that could occur in rare cases. However, the test appears to have issues.

> Invalid async context for servlet: Atmosphere Async  Servlet on JBoss Web
> -------------------------------------------------------------------------
>
>                 Key: JBWEB-205
>                 URL: https://issues.jboss.org/browse/JBWEB-205
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-7.0.0.CR1
>         Environment: Firefox 4.0.1 / Chromium 12 
> AS 6.0.0.Final / 6.1.0-SNAPSHOT / AS 7.0.0.CR1 
> Atmosphere 0.7.1/0.7.2 
>            Reporter: Luk?? Fry?
>            Assignee: Remy Maucherat
>            Priority: Critical
>             Fix For: JBossWeb-7.0.1.GA 
>
>         Attachments: push-jms.war
>
>
> Source of sample for reproduction:
> https://github.com/lfryc/push-jms/commit/9cee160570e049ca4783e1fcbdac25ffef1b10b7
> {code}
> 16:08:28,467 ERROR [org.apache.catalina.connector.CoyoteAdapter] (http-localhost-127.0.0.1-8080-7) An exception or error occurred in the container during the request processing: java.lang.IllegalStateException: Invalid async context for servlet AutoRegisteredPushServlet
> 	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:643) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:402) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:183) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:246) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:128) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:265) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11Processor.event(Http11Processor.java:757) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.event(Http11Protocol.java:615) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:938) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at java.lang.Thread.run(Thread.java:636) [:1.6.0_20]
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Tue Jul  5 06:07:24 2011
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Tue, 5 Jul 2011 06:07:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1145) Composite operation
 with only one member fails
In-Reply-To: <1490230450.27735.1309354643657.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <660413274.35066.1309860444177.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Emanuel Muckenhuber updated AS7-1145:
-------------------------------------

    Fix Version/s: 7.0.0.Final


> Composite operation with only one member fails
> ----------------------------------------------
>
>                 Key: AS7-1145
>                 URL: https://issues.jboss.org/browse/AS7-1145
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.0.0.CR1
>            Reporter: Heiko Rupp
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>             Fix For: 7.0.0.Final
>
>
> I am trying to issue /deployment=foo:add as one step within a composite operation.
> When the composite operation has more than one member, this works.
> If it only has this one member operation, it fails with {"outcome":"failed","failure-description":"No handler for operation add at address [(\"deployment\" => \"test.war\")]","rolled-back":true}
> The failing upload test is in testUploadComposite2 - while all other combinations in that test class work.
> http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=blob;f=modules/plugins/jboss-as-7/src/test/java/org/rhq/modules/plugins/jbossas7/UploadAndDeployTest.java;h=b0d68eedc5553d3ad4adc8236aee6ea537a82092;hb=as7plugin#l299
> The code in question used to work for a long time - I suspect the new-controller work to have broken it. I just checked against an AS7 version from June 16th and there it still works.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 06:14:24 2011
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Tue, 5 Jul 2011 06:14:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1187) parsing server paths
	fails
Message-ID: <164374835.35078.1309860864298.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

parsing server paths fails
--------------------------

                 Key: AS7-1187
                 URL: https://issues.jboss.org/browse/AS7-1187
             Project: Application Server 7
          Issue Type: Bug
    Affects Versions: 7.0.0.CR1
            Reporter: Emanuel Muckenhuber
            Assignee: Emanuel Muckenhuber
             Fix For: 7.0.0.Final




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 07:05:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Tue, 5 Jul 2011 07:05:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1186) EJB interceptor not
	invoked
In-Reply-To: <727231980.34928.1309855103614.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1499754572.35103.1309863923794.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Juergen Zimmermann updated AS7-1186:
------------------------------------

    Affects Version/s: 7.0.0.CR1


> EJB interceptor not invoked
> ---------------------------
>
>                 Key: AS7-1186
>                 URL: https://issues.jboss.org/browse/AS7-1186
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>         Attachments: testcase-src.zip, testcase.ear
>
>
> I'll provide a testcase showing that an EJB 3 interceptor is not invoked although defined in MEAT-INF/ejb-jar.xml.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 08:01:23 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Tue, 5 Jul 2011 08:01:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1188) Possible to remove a
 jdbc driver from a server-group, when still in use
Message-ID: <8676488.35175.1309867283801.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Possible to remove a jdbc driver from a server-group, when still in use
-----------------------------------------------------------------------

                 Key: AS7-1188
                 URL: https://issues.jboss.org/browse/AS7-1188
             Project: Application Server 7
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 7.0.0.CR1
            Reporter: Heiko Rupp
            Assignee: Brian Stansberry


[domain at localhost:9999 /] /server-group=main-server-group/deployment=postgresql-9.0-801.jdbc4.jar:remove
{
    "outcome" => "success",
    "result" => {"server-groups" => [("main-server-group" => {"master" => {
    "host" => "master",
    "response" => {"outcome" => "success"}
}})]}
}
[domain at localhost:9999 /] /profile=default/subsystem=datasources/data-source=postgres:read-resource
{
    "outcome" => "success",
    "result" => {
        "background-validation" => undefined,
        "background-validation-minutes" => undefined,
        "blocking-timeout-wait-millis" => undefined,
        "connection-url" => "jdbc:postgresql://127.0.0.1:5432/rhqdev",
        "driver-name" => "postgresql-9.0-801.jdbc4.jar",


Console says
[Server:server-two] 13:55:09,768 INFO  [org.jboss.as.server.controller] (pool-1-thread-4) Undeployed "postgresql-9.0-801.jdbc4.jar"
[Server:server-two] 13:55:09,769 INFO  [org.jboss.as.controller] (pool-1-thread-4) Service status report
[Server:server-two]    New missing/unsatisfied dependencies:
[Server:server-two]       service jboss.jdbc-driver.postgresql-9_0-801_jdbc4_jar (missing)


and after reboot:

[Server:server-one] 13:58:20,938 INFO  [org.jboss.as.controller] (Controller Boot Thread) Service status report
[Server:server-one]    New missing/unsatisfied dependencies:
[Server:server-one]       service jboss.jdbc-driver.postgresql-9_0-801_jdbc4_jar (missing)


I think removing the driver from a server group should not be possible if a datasource still refers to it.
Basically the same way I can't remove a deployment from /deployment, while still in use in /server-group=x/deployment.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 09:05:31 2011
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Tue, 5 Jul 2011 09:05:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-205) Invalid async
 context for servlet: Atmosphere Async Servlet on JBoss Web
In-Reply-To: <1369266963.32802.1309619303616.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <300624912.35195.1309871131071.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Remy Maucherat commented on JBWEB-205:
--------------------------------------

I did not make any changes to the async code between AS 6 and AS 7 (AS 6 was passing the servlet TCK, and had no bugs that I knew about). Are you certain that the test worked ok with AS 6 ?

> Invalid async context for servlet: Atmosphere Async  Servlet on JBoss Web
> -------------------------------------------------------------------------
>
>                 Key: JBWEB-205
>                 URL: https://issues.jboss.org/browse/JBWEB-205
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-7.0.0.CR1
>         Environment: Firefox 4.0.1 / Chromium 12 
> AS 6.0.0.Final / 6.1.0-SNAPSHOT / AS 7.0.0.CR1 
> Atmosphere 0.7.1/0.7.2 
>            Reporter: Luk?? Fry?
>            Assignee: Remy Maucherat
>            Priority: Critical
>             Fix For: JBossWeb-7.0.1.GA 
>
>         Attachments: push-jms.war
>
>
> Source of sample for reproduction:
> https://github.com/lfryc/push-jms/commit/9cee160570e049ca4783e1fcbdac25ffef1b10b7
> {code}
> 16:08:28,467 ERROR [org.apache.catalina.connector.CoyoteAdapter] (http-localhost-127.0.0.1-8080-7) An exception or error occurred in the container during the request processing: java.lang.IllegalStateException: Invalid async context for servlet AutoRegisteredPushServlet
> 	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:643) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:402) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:183) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:246) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:128) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:265) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11Processor.event(Http11Processor.java:757) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.event(Http11Protocol.java:615) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:938) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at java.lang.Thread.run(Thread.java:636) [:1.6.0_20]
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Tue Jul  5 10:43:23 2011
From: jira-events at lists.jboss.org (Jim Tyrrell (JIRA))
Date: Tue, 5 Jul 2011 10:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1189) When starting up more
 then one instance by accident can the error messages be better currently
 they are kinda long
Message-ID: <135842195.35336.1309877003643.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

When starting up more then one instance by accident can the error messages be better currently they are kinda long
------------------------------------------------------------------------------------------------------------------

                 Key: AS7-1189
                 URL: https://issues.jboss.org/browse/AS7-1189
             Project: Application Server 7
          Issue Type: Feature Request
            Reporter: Jim Tyrrell


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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 10:47:23 2011
From: jira-events at lists.jboss.org (Jim Tyrrell (JIRA))
Date: Tue, 5 Jul 2011 10:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1190) Spring Loading not
	documented
Message-ID: <1365360286.35366.1309877243952.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Spring Loading not documented
-----------------------------

                 Key: AS7-1190
                 URL: https://issues.jboss.org/browse/AS7-1190
             Project: Application Server 7
          Issue Type: Feature Request
            Reporter: Jim Tyrrell


Since Jason in the video I watched mentioned that class loading isolation was a setting and I have a customer provided Spring/hibernate war file provided, I would like to explore these settings, but I can not seem to find where they are documented.  I would think since it was mentioned in the webinar this is a blocker. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 10:47:24 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 5 Jul 2011 10:47:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1087) Infinispan
 transaction timeout on cache stop not set correctly
In-Reply-To: <285678525.13757.1308758603820.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <23057548.35369.1309877244029.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro updated AS7-1087:
------------------------------

    Fix Version/s: 7.0.0.CR1
                       (was: 7.1.0.Alpha1)


> Infinispan transaction timeout on cache stop not set correctly
> --------------------------------------------------------------
>
>                 Key: AS7-1087
>                 URL: https://issues.jboss.org/browse/AS7-1087
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.Beta3
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>            Priority: Minor
>             Fix For: 7.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 10:49:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 5 Jul 2011 10:49:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1087) Infinispan
 transaction timeout on cache stop not set correctly
In-Reply-To: <285678525.13757.1308758603820.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1963885668.35373.1309877363682.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro resolved AS7-1087.
-------------------------------

    Resolution: Done


> Infinispan transaction timeout on cache stop not set correctly
> --------------------------------------------------------------
>
>                 Key: AS7-1087
>                 URL: https://issues.jboss.org/browse/AS7-1087
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.Beta3
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>            Priority: Minor
>             Fix For: 7.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 11:17:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 5 Jul 2011 11:17:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1188) Possible to remove a
 jdbc driver from a server-group, when still in use
In-Reply-To: <8676488.35175.1309867283801.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <961383581.35458.1309879044193.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-1188:
----------------------------------

    Component/s: JCA


I see two issues here:

1) The removal created an unsatisfied dependency, as the console logging shows, but that unsatisfied dependency did not trigger a rollback of the operation. I think this is a general problem, where the ServiceVerificationHandler mechanism used to detect errors caused by runtime ops does not deal with service removals.

2) Whether or not the driver removal should be allowed, resulting in a cascading removal of the datasource and anything that depends on the datasource. Based on the console logging it seems this isn't meant to happen. Heiko in the JIRA description expresses an opinion that it shouldn't happen. I think that's fine; don't let it happen.

> Possible to remove a jdbc driver from a server-group, when still in use
> -----------------------------------------------------------------------
>
>                 Key: AS7-1188
>                 URL: https://issues.jboss.org/browse/AS7-1188
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management, JCA
>    Affects Versions: 7.0.0.CR1
>            Reporter: Heiko Rupp
>            Assignee: Brian Stansberry
>
> [domain at localhost:9999 /] /server-group=main-server-group/deployment=postgresql-9.0-801.jdbc4.jar:remove
> {
>     "outcome" => "success",
>     "result" => {"server-groups" => [("main-server-group" => {"master" => {
>     "host" => "master",
>     "response" => {"outcome" => "success"}
> }})]}
> }
> [domain at localhost:9999 /] /profile=default/subsystem=datasources/data-source=postgres:read-resource
> {
>     "outcome" => "success",
>     "result" => {
>         "background-validation" => undefined,
>         "background-validation-minutes" => undefined,
>         "blocking-timeout-wait-millis" => undefined,
>         "connection-url" => "jdbc:postgresql://127.0.0.1:5432/rhqdev",
>         "driver-name" => "postgresql-9.0-801.jdbc4.jar",
> Console says
> [Server:server-two] 13:55:09,768 INFO  [org.jboss.as.server.controller] (pool-1-thread-4) Undeployed "postgresql-9.0-801.jdbc4.jar"
> [Server:server-two] 13:55:09,769 INFO  [org.jboss.as.controller] (pool-1-thread-4) Service status report
> [Server:server-two]    New missing/unsatisfied dependencies:
> [Server:server-two]       service jboss.jdbc-driver.postgresql-9_0-801_jdbc4_jar (missing)
> and after reboot:
> [Server:server-one] 13:58:20,938 INFO  [org.jboss.as.controller] (Controller Boot Thread) Service status report
> [Server:server-one]    New missing/unsatisfied dependencies:
> [Server:server-one]       service jboss.jdbc-driver.postgresql-9_0-801_jdbc4_jar (missing)
> I think removing the driver from a server group should not be possible if a datasource still refers to it.
> Basically the same way I can't remove a deployment from /deployment, while still in use in /server-group=x/deployment.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 11:21:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 5 Jul 2011 11:21:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1164) add jdbc-driver :
 documentation incomplete or misleading
In-Reply-To: <2061849607.31723.1309511903626.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <267376715.35512.1309879284274.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-1164:
----------------------------------

       Assignee: Stefano Maestri  (was: Brian Stansberry)
    Component/s: JCA


Assigning to Stefano as this appears to be related to the details of the JCA subsystem and not some general issue with the management infrastructure.

> add jdbc-driver : documentation incomplete or misleading
> --------------------------------------------------------
>
>                 Key: AS7-1164
>                 URL: https://issues.jboss.org/browse/AS7-1164
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management, JCA
>    Affects Versions: 7.0.0.CR1
>            Reporter: Heiko Rupp
>            Assignee: Stefano Maestri
>
> I want to add a jdbc driver to a profile. The driver has been uploaded to /deployment
> [domain at localhost:9999 subsystem=datasources] pwd
> /profile=default/subsystem=datasources
> [domain at localhost:9999 subsystem=datasources] ./jdbc-driver=postgres9:add(driver-name=postgres9,deployment-name=postgresql-9.0-801.jdbc4.jar,driver-class-name=org.postgresql.Driver)
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "Operation handler failed: java.util.NoSuchElementException: No child 'driver-module-name' exists"},
>     "rolled-back" => true
> }
> Documentation says:
> [domain at localhost:9999 jdbc-driver=h2] :read-operation-description(name=add)                 
> {
>     "outcome" => "success",
>     "result" => {
>         "operation-name" => "add",
>         "description" => "Adds a new JDBC driver service",
>         "attributes" => {
>             "driver-name" => {
>                 "description" => "The symbolic name of this driver used to reference it in the register",
>                 "type" => STRING,
>                 "required" => true
>             },
>             "deployment-name" => {
>                 "description" => "The name of the deployment unit from which the driver was loaded, if it was loaded from a deployment",
>                 "type" => STRING
>             },
>             "driver-module-name" => {
>                 "description" => "The name of the module from which the driver was loaded, if it was loaded from the module path",
>                 "type" => STRING
>             },
>             "module-slot" => {
>                 "description" => "The slot of the module from which the driver was loaded, if it was loaded from the module path",
>                 "type" => STRING
>             },
>             "driver-class-name" => {
>                 "description" => "The fully qualified class name of the driver's implementation of java.sql.Driver",
>                 "type" => STRING
>             },
>             "driver-major-version" => {
>                 "description" => "The driver's major version number",
>                 "type" => INT
>             },
>             "driver-minor-version" => {
>                 "description" => "The driver's minor version number",
>                 "type" => INT
>             },
>             "jdbc-compliant" => {
>                 "description" => "Whether or not the driver is JDBC compliant",
>                 "type" => BOOLEAN
>             }
>         }
>     }
> }
> Here, only the driver-name is required.
> For driver-module-name it says "if loaded from module", which I read as "optional".
> Obviously from above error message, this is not optional

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 13:06:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 5 Jul 2011 13:06:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1033) Complete the
 "securing the admin console" documentation
In-Reply-To: <1912892898.471.1308219203742.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1646445830.35756.1309885583669.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse resolved AS7-1033.
-----------------------------------

    Resolution: Done


> Complete the "securing the admin console" documentation
> -------------------------------------------------------
>
>                 Key: AS7-1033
>                 URL: https://issues.jboss.org/browse/AS7-1033
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 7.0.0.Final
>
>
> https://docs.jboss.org/author/display/AS7/Admin+Guide?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 13:10:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 5 Jul 2011 13:10:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-943) Out Of The Box -
 Management Security
In-Reply-To: <1482583926.1093.1307031119453.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <358601595.35760.1309885823697.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse resolved AS7-943.
----------------------------------

    Resolution: Done


> Out Of The Box - Management Security
> ------------------------------------
>
>                 Key: AS7-943
>                 URL: https://issues.jboss.org/browse/AS7-943
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>             Fix For: 7.0.0.Final
>
>
> After lots of back and forth, the plan is to:
> 1) Ship unsecured
> 2) Ship a secure-mgmt.cli script that can be executed from the CLI
> ./jboss-admin.sh --file secure-mgmt.cli
> 3) Include in the domain/configuration and standalone/configuration dirs a properties file with a commented out user
> #admin=CHANGEIT 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 13:32:23 2011
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Tue, 5 Jul 2011 13:32:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1187) parsing server paths
	fails
In-Reply-To: <164374835.35078.1309860864298.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1642819860.35790.1309887143615.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Emanuel Muckenhuber resolved AS7-1187.
--------------------------------------

    Resolution: Done


> parsing server paths fails
> --------------------------
>
>                 Key: AS7-1187
>                 URL: https://issues.jboss.org/browse/AS7-1187
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.CR1
>            Reporter: Emanuel Muckenhuber
>            Assignee: Emanuel Muckenhuber
>             Fix For: 7.0.0.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 13:34:23 2011
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Tue, 5 Jul 2011 13:34:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1145) Composite operation
 with only one member fails
In-Reply-To: <1490230450.27735.1309354643657.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1555401189.35794.1309887263651.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Emanuel Muckenhuber resolved AS7-1145.
--------------------------------------

    Resolution: Done


> Composite operation with only one member fails
> ----------------------------------------------
>
>                 Key: AS7-1145
>                 URL: https://issues.jboss.org/browse/AS7-1145
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.0.0.CR1
>            Reporter: Heiko Rupp
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>             Fix For: 7.0.0.Final
>
>
> I am trying to issue /deployment=foo:add as one step within a composite operation.
> When the composite operation has more than one member, this works.
> If it only has this one member operation, it fails with {"outcome":"failed","failure-description":"No handler for operation add at address [(\"deployment\" => \"test.war\")]","rolled-back":true}
> The failing upload test is in testUploadComposite2 - while all other combinations in that test class work.
> http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=blob;f=modules/plugins/jboss-as-7/src/test/java/org/rhq/modules/plugins/jbossas7/UploadAndDeployTest.java;h=b0d68eedc5553d3ad4adc8236aee6ea537a82092;hb=as7plugin#l299
> The code in question used to work for a long time - I suspect the new-controller work to have broken it. I just checked against an AS7 version from June 16th and there it still works.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 14:04:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 5 Jul 2011 14:04:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1182)
 DatabaseServerLoginModule doesn't work
In-Reply-To: <320201656.33784.1309788924180.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <801970017.35805.1309889063668.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse reassigned AS7-1182:
-------------------------------------

    Assignee: Darran Lofthouse


> DatabaseServerLoginModule doesn't work
> --------------------------------------
>
>                 Key: AS7-1182
>                 URL: https://issues.jboss.org/browse/AS7-1182
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: Darran Lofthouse
>
> I want to migrate from JBossAS 6 to 7.0.0.CR1. In standalone.xml I declare the following security domain, but get the stacktrace (see below) looking for UsersRolesLoginModule instead of DatabaseServerLoginModule.
> Security domain in standalone.xml:
>    <security-domain name="swe2" cache-type="default">
>       <authentication>
>          <login-module code="Database" flag="required">
>             <module-option name="dsJndiName" value="java:/swe2DS"/>
>             <module-option name="unauthenticatedIdentity" value="gast"/>
>             <module-option name="principalsQuery" value="SELECT password FROM kunde WHERE username=?"/>
>             <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM swe2_role r INNER JOIN kunde k ON r.kunde_fk = k.k_id WHERE k.username=?"/>
>             <module-option name="hashAlgorithm" value="SHA-1"/>
>             <module-option name="hashEncoding" value="base64"/>
>          </login-module>
>       </authentication>
>    </security-domain>
> Stacktrace regarding UsersRolesLoginModule (instead of DatabaseServerLoginModule):
> 16:03:58,528 ERROR [org.jboss.security.auth.spi.UsersRolesLoginModule] (http--127.0.0.1-8080-2) Failed to load users/passwords/role files: java.io.IOException: No properties file: users.properties or defaults: defaultUsers.properties found
> 	at org.jboss.security.auth.spi.Util.loadProperties(Util.java:227) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:188) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:202) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:129) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	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 javax.security.auth.login.LoginContext.invoke(LoginContext.java:756) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683) [:1.6.0_26]
> 	at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:579) [:1.6.0_26]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:411) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:154) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:127) [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:180) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:446) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 14:06:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 5 Jul 2011 14:06:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1182) Incorrect security
 domain selected for web application.
In-Reply-To: <320201656.33784.1309788924180.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1005154149.35809.1309889183691.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated AS7-1182:
----------------------------------

    Summary: Incorrect security domain selected for web application.  (was: DatabaseServerLoginModule doesn't work)


> Incorrect security domain selected for web application.
> -------------------------------------------------------
>
>                 Key: AS7-1182
>                 URL: https://issues.jboss.org/browse/AS7-1182
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: Darran Lofthouse
>
> I want to migrate from JBossAS 6 to 7.0.0.CR1. In standalone.xml I declare the following security domain, but get the stacktrace (see below) looking for UsersRolesLoginModule instead of DatabaseServerLoginModule.
> Security domain in standalone.xml:
>    <security-domain name="swe2" cache-type="default">
>       <authentication>
>          <login-module code="Database" flag="required">
>             <module-option name="dsJndiName" value="java:/swe2DS"/>
>             <module-option name="unauthenticatedIdentity" value="gast"/>
>             <module-option name="principalsQuery" value="SELECT password FROM kunde WHERE username=?"/>
>             <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM swe2_role r INNER JOIN kunde k ON r.kunde_fk = k.k_id WHERE k.username=?"/>
>             <module-option name="hashAlgorithm" value="SHA-1"/>
>             <module-option name="hashEncoding" value="base64"/>
>          </login-module>
>       </authentication>
>    </security-domain>
> Stacktrace regarding UsersRolesLoginModule (instead of DatabaseServerLoginModule):
> 16:03:58,528 ERROR [org.jboss.security.auth.spi.UsersRolesLoginModule] (http--127.0.0.1-8080-2) Failed to load users/passwords/role files: java.io.IOException: No properties file: users.properties or defaults: defaultUsers.properties found
> 	at org.jboss.security.auth.spi.Util.loadProperties(Util.java:227) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:188) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:202) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:129) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	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 javax.security.auth.login.LoginContext.invoke(LoginContext.java:756) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683) [:1.6.0_26]
> 	at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:579) [:1.6.0_26]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:411) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:154) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:127) [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:180) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:446) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 14:08:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 5 Jul 2011 14:08:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1148) After startup and
 shutdown of the AS 7 CR 1 release,
 the async-handler configuration gets overwritten with improper element
 (subhandlers are changed to handlers),
 and it won't start again with editing the configuration.
In-Reply-To: <874381484.28835.1309392563628.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2014386906.35817.1309889303748.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd updated AS7-1148:
-----------------------------

       Assignee: David Lloyd
    Component/s: Logging


> After startup and shutdown of the AS 7 CR 1 release, the async-handler configuration gets overwritten with improper element (subhandlers are changed to handlers), and it won't start again with editing the configuration.
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1148
>                 URL: https://issues.jboss.org/browse/AS7-1148
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management, Logging
>    Affects Versions: 7.0.0.CR1
>            Reporter: Andrig Miller
>            Assignee: David Lloyd
>            Priority: Critical
>             Fix For: 7.0.0.Final
>
>
> I created a configuration to use asynchronous logging in standalone-ha.xml, and after successfully starting the server, running a test, and shutting it down, I could no longer restart the server without a parse error in standalone-ha.xml.
> What is happening, is the file is being rewritten, and it is replacing the subhandlers element with a handlers element which is incorrect.
> So, my configuration, that looks like this when I start the server:
> <subsystem xmlns="urn:jboss:domain:logging:1.0">
>             <async-handler name="ASYNC">
>                 <level name="INFO"/>
>                 <queue-length value="1024"/>
>                 <overflow-action value="BLOCK"/>
>                 <subhandlers>
>                     <handler name="FILE"/>
>                 </subhandlers>
>             </async-handler>
>             <periodic-rotating-file-handler name="FILE" autoflush="true">
>                 <level name="INFO"/>
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <suffix value=".yyyy-MM-dd"/>
>             </periodic-rotating-file-handler>
>             <logger category="com.arjuna">
>                 <level name="WARN"/>
>             </logger>
>             <logger category="org.apache.tomcat.util.modeler">
>                 <level name="WARN"/>
>             </logger>
>             <logger category="sun.rmi">
>                 <level name="WARN"/>
>             </logger>
>             <root-logger>
>                 <level name="INFO"/>
>                 <handlers>
>                     <handler name="ASYNC"/>
>                 </handlers>
>             </root-logger>
>         </subsystem>
> ends up looking like this:
> <subsystem xmlns="urn:jboss:domain:logging:1.0">
>             <async-handler name="ASYNC">
>                 <level name="INFO"/>
>                 <queue-length value="1024"/>
>                 <overflow-action value="BLOCK"/>
>                 <handlers>
>                     <handler name="FILE"/>
>                 </handlers>
>             </async-handler>
>             <periodic-rotating-file-handler name="FILE" autoflush="true">
>                 <level name="INFO"/>
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <suffix value=".yyyy-MM-dd"/>
>             </periodic-rotating-file-handler>
>             <logger category="com.arjuna">
>                 <level name="WARN"/>
>             </logger>
>             <logger category="org.apache.tomcat.util.modeler">
>                 <level name="WARN"/>
>             </logger>
>             <logger category="sun.rmi">
>                 <level name="WARN"/>
>             </logger>
>             <root-logger>
>                 <level name="INFO"/>
>                 <handlers>
>                     <handler name="ASYNC"/>
>                 </handlers>
>             </root-logger>
>         </subsystem>
> Which is wrong and fails parsing, which prevents the server from starting again, unless I hand edit the file again to correct it.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 14:08:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 5 Jul 2011 14:08:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1182) Incorrect security
 domain selected for web application.
In-Reply-To: <320201656.33784.1309788924180.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1618661157.35820.1309889303818.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse commented on AS7-1182:
---------------------------------------

Juergen, do you have a thread started for this in the AS7 Users discussions?  

It would be helpful to see how the web application is being associated with the security domain as the error suggests to me that the 'other' domain is being picked up instead of your domain rather than an issue with the login module itself.

> Incorrect security domain selected for web application.
> -------------------------------------------------------
>
>                 Key: AS7-1182
>                 URL: https://issues.jboss.org/browse/AS7-1182
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: Darran Lofthouse
>
> I want to migrate from JBossAS 6 to 7.0.0.CR1. In standalone.xml I declare the following security domain, but get the stacktrace (see below) looking for UsersRolesLoginModule instead of DatabaseServerLoginModule.
> Security domain in standalone.xml:
>    <security-domain name="swe2" cache-type="default">
>       <authentication>
>          <login-module code="Database" flag="required">
>             <module-option name="dsJndiName" value="java:/swe2DS"/>
>             <module-option name="unauthenticatedIdentity" value="gast"/>
>             <module-option name="principalsQuery" value="SELECT password FROM kunde WHERE username=?"/>
>             <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM swe2_role r INNER JOIN kunde k ON r.kunde_fk = k.k_id WHERE k.username=?"/>
>             <module-option name="hashAlgorithm" value="SHA-1"/>
>             <module-option name="hashEncoding" value="base64"/>
>          </login-module>
>       </authentication>
>    </security-domain>
> Stacktrace regarding UsersRolesLoginModule (instead of DatabaseServerLoginModule):
> 16:03:58,528 ERROR [org.jboss.security.auth.spi.UsersRolesLoginModule] (http--127.0.0.1-8080-2) Failed to load users/passwords/role files: java.io.IOException: No properties file: users.properties or defaults: defaultUsers.properties found
> 	at org.jboss.security.auth.spi.Util.loadProperties(Util.java:227) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:188) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:202) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:129) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	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 javax.security.auth.login.LoginContext.invoke(LoginContext.java:756) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683) [:1.6.0_26]
> 	at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:579) [:1.6.0_26]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:411) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:154) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:127) [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:180) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:446) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 14:10:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 5 Jul 2011 14:10:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1148) After startup and
 shutdown of the AS 7 CR 1 release,
 the async-handler configuration gets overwritten with improper element
 (subhandlers are changed to handlers),
 and it won't start again with editing the configuration.
In-Reply-To: <874381484.28835.1309392563628.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <524151419.35827.1309889423788.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd resolved AS7-1148.
------------------------------

    Resolution: Done


> After startup and shutdown of the AS 7 CR 1 release, the async-handler configuration gets overwritten with improper element (subhandlers are changed to handlers), and it won't start again with editing the configuration.
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1148
>                 URL: https://issues.jboss.org/browse/AS7-1148
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management, Logging
>    Affects Versions: 7.0.0.CR1
>            Reporter: Andrig Miller
>            Assignee: David Lloyd
>            Priority: Critical
>             Fix For: 7.0.0.Final
>
>
> I created a configuration to use asynchronous logging in standalone-ha.xml, and after successfully starting the server, running a test, and shutting it down, I could no longer restart the server without a parse error in standalone-ha.xml.
> What is happening, is the file is being rewritten, and it is replacing the subhandlers element with a handlers element which is incorrect.
> So, my configuration, that looks like this when I start the server:
> <subsystem xmlns="urn:jboss:domain:logging:1.0">
>             <async-handler name="ASYNC">
>                 <level name="INFO"/>
>                 <queue-length value="1024"/>
>                 <overflow-action value="BLOCK"/>
>                 <subhandlers>
>                     <handler name="FILE"/>
>                 </subhandlers>
>             </async-handler>
>             <periodic-rotating-file-handler name="FILE" autoflush="true">
>                 <level name="INFO"/>
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <suffix value=".yyyy-MM-dd"/>
>             </periodic-rotating-file-handler>
>             <logger category="com.arjuna">
>                 <level name="WARN"/>
>             </logger>
>             <logger category="org.apache.tomcat.util.modeler">
>                 <level name="WARN"/>
>             </logger>
>             <logger category="sun.rmi">
>                 <level name="WARN"/>
>             </logger>
>             <root-logger>
>                 <level name="INFO"/>
>                 <handlers>
>                     <handler name="ASYNC"/>
>                 </handlers>
>             </root-logger>
>         </subsystem>
> ends up looking like this:
> <subsystem xmlns="urn:jboss:domain:logging:1.0">
>             <async-handler name="ASYNC">
>                 <level name="INFO"/>
>                 <queue-length value="1024"/>
>                 <overflow-action value="BLOCK"/>
>                 <handlers>
>                     <handler name="FILE"/>
>                 </handlers>
>             </async-handler>
>             <periodic-rotating-file-handler name="FILE" autoflush="true">
>                 <level name="INFO"/>
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <suffix value=".yyyy-MM-dd"/>
>             </periodic-rotating-file-handler>
>             <logger category="com.arjuna">
>                 <level name="WARN"/>
>             </logger>
>             <logger category="org.apache.tomcat.util.modeler">
>                 <level name="WARN"/>
>             </logger>
>             <logger category="sun.rmi">
>                 <level name="WARN"/>
>             </logger>
>             <root-logger>
>                 <level name="INFO"/>
>                 <handlers>
>                     <handler name="ASYNC"/>
>                 </handlers>
>             </root-logger>
>         </subsystem>
> Which is wrong and fails parsing, which prevents the server from starting again, unless I hand edit the file again to correct it.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 14:10:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 5 Jul 2011 14:10:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1149) ASYNC logging logs
 nothing to the server.log
In-Reply-To: <345655314.28831.1309392203647.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1387581683.35830.1309889423871.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd updated AS7-1149:
-----------------------------

    Component/s: Logging


> ASYNC logging logs nothing to the server.log
> --------------------------------------------
>
>                 Key: AS7-1149
>                 URL: https://issues.jboss.org/browse/AS7-1149
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.0.0.Beta3
>            Reporter: Andrig Miller
>            Assignee: David Lloyd
>            Priority: Critical
>             Fix For: 7.1.0.Alpha1
>
>
> I configured AS 7 CR 1 to use Asynchronous logging as that release had the fix in it to have it parse the configuration correctly, but nothing ever gets written to the server.log.
> My configuration is as follows:
> <subsystem xmlns="urn:jboss:domain:logging:1.0">
>             <async-handler name="ASYNC">
>                 <level name="INFO"/>
>                 <queue-length value="1024"/>
>                 <overflow-action value="BLOCK"/>
>                 <subhandlers>
>                     <handler name="FILE"/>
>                 </subhandlers>
>             </async-handler>
>             <periodic-rotating-file-handler name="FILE" autoflush="true">
>                 <level name="INFO"/>
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <suffix value=".yyyy-MM-dd"/>
>             </periodic-rotating-file-handler>
>             <logger category="com.arjuna">
>                 <level name="WARN"/>
>             </logger>
>             <logger category="org.apache.tomcat.util.modeler">
>                 <level name="WARN"/>
>             </logger>
>             <logger category="sun.rmi">
>                 <level name="WARN"/>
>             </logger>
>             <root-logger>
>                 <level name="INFO"/>
>                 <handlers>
>                     <handler name="ASYNC"/>
>                 </handlers>
>             </root-logger>
>         </subsystem>

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 14:10:24 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 5 Jul 2011 14:10:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1149) ASYNC logging logs
 nothing to the server.log
In-Reply-To: <345655314.28831.1309392203647.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <629745943.35834.1309889424065.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd resolved AS7-1149.
------------------------------

    Resolution: Duplicate Issue


Duplicates AS7-1150

> ASYNC logging logs nothing to the server.log
> --------------------------------------------
>
>                 Key: AS7-1149
>                 URL: https://issues.jboss.org/browse/AS7-1149
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.0.0.Beta3
>            Reporter: Andrig Miller
>            Assignee: David Lloyd
>            Priority: Critical
>             Fix For: 7.1.0.Alpha1
>
>
> I configured AS 7 CR 1 to use Asynchronous logging as that release had the fix in it to have it parse the configuration correctly, but nothing ever gets written to the server.log.
> My configuration is as follows:
> <subsystem xmlns="urn:jboss:domain:logging:1.0">
>             <async-handler name="ASYNC">
>                 <level name="INFO"/>
>                 <queue-length value="1024"/>
>                 <overflow-action value="BLOCK"/>
>                 <subhandlers>
>                     <handler name="FILE"/>
>                 </subhandlers>
>             </async-handler>
>             <periodic-rotating-file-handler name="FILE" autoflush="true">
>                 <level name="INFO"/>
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <suffix value=".yyyy-MM-dd"/>
>             </periodic-rotating-file-handler>
>             <logger category="com.arjuna">
>                 <level name="WARN"/>
>             </logger>
>             <logger category="org.apache.tomcat.util.modeler">
>                 <level name="WARN"/>
>             </logger>
>             <logger category="sun.rmi">
>                 <level name="WARN"/>
>             </logger>
>             <root-logger>
>                 <level name="INFO"/>
>                 <handlers>
>                     <handler name="ASYNC"/>
>                 </handlers>
>             </root-logger>
>         </subsystem>

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 14:14:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 5 Jul 2011 14:14:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1150) Asynchronous
 logging doesn't work.
In-Reply-To: <1448450116.28842.1309392803638.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1788359242.35838.1309889663634.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd commented on AS7-1150:
----------------------------------

Reformatted for readability:

{code:xml}
<subsystem xmlns="urn:jboss:domain:logging:1.0">
  <async-handler name="ASYNC">
    <level name="INFO"/>
    <queue-length value="1024"/>
    <overflow-action value="BLOCK"/>
    <subhandlers>
      <handler name="FILE"/>
    </subhandlers>
  </async-handler>
  <periodic-rotating-file-handler name="FILE" autoflush="true">
    <level name="INFO"/>
    <formatter>
      <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
    </formatter>
    <file relative-to="jboss.server.log.dir" path="server.log"/>
    <suffix value=".yyyy-MM-dd"/>
  </periodic-rotating-file-handler>
  <logger category="com.arjuna">
    <level name="WARN"/>
  </logger>
  <logger category="org.apache.tomcat.util.modeler">
    <level name="WARN"/>
  </logger>
  <logger category="sun.rmi">
    <level name="WARN"/>
  </logger>
  <root-logger>
    <level name="INFO"/>
    <handlers>
      <handler name="ASYNC"/>
    </handlers>
  </root-logger>
</subsystem>
{code}

> Asynchronous logging doesn't work.
> ----------------------------------
>
>                 Key: AS7-1150
>                 URL: https://issues.jboss.org/browse/AS7-1150
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.0.0.CR1
>            Reporter: Andrig Miller
>            Priority: Critical
>             Fix For: 7.0.0.Final
>
>
> Asynchronous logging writes nothing to the server.log.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 14:25:23 2011
From: jira-events at lists.jboss.org (Jay Balunas (JIRA))
Date: Tue, 5 Jul 2011 14:25:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-205) Invalid async
 context for servlet: Atmosphere Async Servlet on JBoss Web
In-Reply-To: <1369266963.32802.1309619303616.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1308358118.35858.1309890323698.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jay Balunas commented on JBWEB-205:
-----------------------------------

I am not certain, as you said the issue is not easy to reproduce, and is intermittent.  I'm assuming the issue was not reproduced, and then closed.  Lukas reported said he was able to reproduce on AS6 in the bug.  

Lukas will be back at work tomorrow and we will follow up.

Would the issue you saw be caught by the TCK?

> Invalid async context for servlet: Atmosphere Async  Servlet on JBoss Web
> -------------------------------------------------------------------------
>
>                 Key: JBWEB-205
>                 URL: https://issues.jboss.org/browse/JBWEB-205
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-7.0.0.CR1
>         Environment: Firefox 4.0.1 / Chromium 12 
> AS 6.0.0.Final / 6.1.0-SNAPSHOT / AS 7.0.0.CR1 
> Atmosphere 0.7.1/0.7.2 
>            Reporter: Luk?? Fry?
>            Assignee: Remy Maucherat
>            Priority: Critical
>             Fix For: JBossWeb-7.0.1.GA 
>
>         Attachments: push-jms.war
>
>
> Source of sample for reproduction:
> https://github.com/lfryc/push-jms/commit/9cee160570e049ca4783e1fcbdac25ffef1b10b7
> {code}
> 16:08:28,467 ERROR [org.apache.catalina.connector.CoyoteAdapter] (http-localhost-127.0.0.1-8080-7) An exception or error occurred in the container during the request processing: java.lang.IllegalStateException: Invalid async context for servlet AutoRegisteredPushServlet
> 	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:643) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:402) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:183) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:246) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:128) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:265) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11Processor.event(Http11Processor.java:757) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.event(Http11Protocol.java:615) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:938) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at java.lang.Thread.run(Thread.java:636) [:1.6.0_20]
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Tue Jul  5 15:17:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 5 Jul 2011 15:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1150) Asynchronous logging
 doesn't work.
In-Reply-To: <1448450116.28842.1309392803638.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1437286958.35908.1309893443659.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd resolved AS7-1150.
------------------------------

      Assignee: David Lloyd
    Resolution: Done


> Asynchronous logging doesn't work.
> ----------------------------------
>
>                 Key: AS7-1150
>                 URL: https://issues.jboss.org/browse/AS7-1150
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.0.0.CR1
>            Reporter: Andrig Miller
>            Assignee: David Lloyd
>            Priority: Critical
>             Fix For: 7.0.0.Final
>
>
> Asynchronous logging writes nothing to the server.log.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 15:25:24 2011
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 5 Jul 2011 15:25:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1150) Asynchronous
 logging doesn't work.
In-Reply-To: <1448450116.28842.1309392803638.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <151128431.35933.1309893924535.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stan Silvert commented on AS7-1150:
-----------------------------------

David,

A few questions that will help with getting this into console:

What are the accepted values for overflow-action?
Is overflow-action required when adding an async-handler?
What should the default value be for overflow-action?
Is 1024 an good default for queue-length?
Is it OK to create an async-handler that doesn't currently have a subhandler?

FYI, I tried out your async-handler declaration in standalone.xml and I was able to display it in the CLI.  However, :read-operation-description(name=add) for async-handler didn't show the overflow-action and subhandler attributes.

> Asynchronous logging doesn't work.
> ----------------------------------
>
>                 Key: AS7-1150
>                 URL: https://issues.jboss.org/browse/AS7-1150
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.0.0.CR1
>            Reporter: Andrig Miller
>            Assignee: David Lloyd
>            Priority: Critical
>             Fix For: 7.0.0.Final
>
>
> Asynchronous logging writes nothing to the server.log.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 16:09:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 5 Jul 2011 16:09:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1191) Cache listener events
 in DistributedCacheManager throwing CNFEs during Event.getKey()
Message-ID: <1763090635.36156.1309896563659.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Cache listener events in DistributedCacheManager throwing CNFEs during Event.getKey()
-------------------------------------------------------------------------------------

                 Key: AS7-1191
                 URL: https://issues.jboss.org/browse/AS7-1191
             Project: Application Server 7
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 7.0.0.CR1
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
            Priority: Blocker
             Fix For: 7.0.0.Final


Because we're using a custom key to store web sessions, Event.getKey() needs to deserialize key using the correct classloader.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 16:09:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 5 Jul 2011 16:09:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1191) Cache listener
 events in DistributedCacheManager throwing CNFEs during Event.getKey()
In-Reply-To: <1763090635.36156.1309896563659.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1757692918.36158.1309896563705.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro commented on AS7-1191:
-----------------------------------

Fix on the way...

> Cache listener events in DistributedCacheManager throwing CNFEs during Event.getKey()
> -------------------------------------------------------------------------------------
>
>                 Key: AS7-1191
>                 URL: https://issues.jboss.org/browse/AS7-1191
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.CR1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>            Priority: Blocker
>             Fix For: 7.0.0.Final
>
>
> Because we're using a custom key to store web sessions, Event.getKey() needs to deserialize key using the correct classloader.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 16:21:23 2011
From: jira-events at lists.jboss.org (shashi mhatre (JIRA))
Date: Tue, 5 Jul 2011 16:21:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3120) Error - no
 visitor implementation for : class org.jbpm.ruleflow.core.RuleFlowProcess
Message-ID: <1184834723.36188.1309897283615.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Error - no visitor implementation for : class org.jbpm.ruleflow.core.RuleFlowProcess
------------------------------------------------------------------------------------

                 Key: JBRULES-3120
                 URL: https://issues.jboss.org/browse/JBRULES-3120
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core (flow)
    Affects Versions: 5.1.0.FINAL
         Environment: Windows XP, Java 1.6.23
            Reporter: shashi mhatre
            Assignee: Mark Proctor


Drools KnowledgeAgent print below message on console after executing rules.

"no visitor implementation for : class org.jbpm.ruleflow.core.RuleFlowProcess : org.jbpm.ruleflow.core.RuleFlowProcess at 5d5660fe"

This happens when "NewInstance" property of the knowledgeAgent is set to false.

I have configured one BPMN process and a simple DRL file in the changeset.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 17:22:23 2011
From: jira-events at lists.jboss.org (Gerry Matte (JIRA))
Date: Tue, 5 Jul 2011 17:22:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1192) Classloader
 Thread.currentThread().getContextClassLoader() no longer inspects
 WEB-INF/lib
Message-ID: <1360489738.36304.1309900943699.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Classloader Thread.currentThread().getContextClassLoader() no longer inspects WEB-INF/lib
-----------------------------------------------------------------------------------------

                 Key: AS7-1192
                 URL: https://issues.jboss.org/browse/AS7-1192
             Project: Application Server 7
          Issue Type: Bug
          Components: Naming, Web
    Affects Versions: 7.0.0.CR1
         Environment: Windows 7 64 bit with java 1.6 U24 installed (both 64 bit - default version) and with 32 bit installed.
Eclipse Indigo 32 bit running with 32 bit jvm by using command line option  -vm C:\s\java32\bin\javaw.exe
JBoss Tools 3.3.0-M2 installed within Eclipse

Jboss AS 7.0.0.CR1 running using 64 bit JVM from Dos using unmodified standalone.bat
Also when started via Eclipse server runtime.
            Reporter: Gerry Matte


Web applications on JBoss AS 6 and earlier could use the class loader to find and load a properties file stored in WEB/lib

Jboss 7 seems to not find the properties file.

Until now I believed that this folder was considered to be part of the classpath for a webapp.  Perhaps it is not ?

I will attach a test eclipse project and a war file either to this bug report or to the forum posting.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 17:22:23 2011
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Tue, 5 Jul 2011 17:22:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1165) Improve error
 message(s) of deployment failures
In-Reply-To: <797335313.31854.1309516043727.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <283361432.36307.1309900943840.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

SBS JIRA Integration updated AS7-1165:
--------------------------------------

    Forum Reference: http://community.jboss.org/message/613349#613349, http://community.jboss.org/message/612943#612943, http://community.jboss.org/message/612545#612545  (was: http://community.jboss.org/message/612943#612943, http://community.jboss.org/message/612545#612545)


> Improve error message(s) of deployment failures 
> ------------------------------------------------
>
>                 Key: AS7-1165
>                 URL: https://issues.jboss.org/browse/AS7-1165
>             Project: Application Server 7
>          Issue Type: Enhancement
>    Affects Versions: 7.0.0.CR1
>            Reporter: jaikiran pai
>            Assignee: Stuart Douglas
>             Fix For: 7.0.0.Final
>
>
> The error reporting in 7.0.0.CR1 for deployment failures due to missing dependencies is very complex and almost cannot be understood. Here are a couple of examples:
> http://community.jboss.org/message/612943#612943
> http://community.jboss.org/message/612555#612555
> This needs to be improved in later versions.
> I'm marking this as "Fix Version" 7.1.0.Alpha1 because I guess this isn't an easy change to incorporate in 7.0.0.Final. If it's possible to get this in for 7.0.0.Final then please change it accordingly.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 17:24:23 2011
From: jira-events at lists.jboss.org (Gerry Matte (JIRA))
Date: Tue, 5 Jul 2011 17:24:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1192) Classloader
 Thread.currentThread().getContextClassLoader() no longer inspects
 WEB-INF/lib
In-Reply-To: <1360489738.36304.1309900943699.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <849581437.36311.1309901063629.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Gerry Matte updated AS7-1192:
-----------------------------

    Attachment: readme.txt
                eclipse-as7.log
                jndiTests.war.zip
                jndiTests.zip


eclipse-as7.log is the eclipse log 
jndiTests.war.zip is the war folder from {JBOSS_HOME]\standalone\deployments 
jndiTests.zip is the eclipse project 


> Classloader Thread.currentThread().getContextClassLoader() no longer inspects WEB-INF/lib
> -----------------------------------------------------------------------------------------
>
>                 Key: AS7-1192
>                 URL: https://issues.jboss.org/browse/AS7-1192
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Naming, Web
>    Affects Versions: 7.0.0.CR1
>         Environment: Windows 7 64 bit with java 1.6 U24 installed (both 64 bit - default version) and with 32 bit installed.
> Eclipse Indigo 32 bit running with 32 bit jvm by using command line option  -vm C:\s\java32\bin\javaw.exe
> JBoss Tools 3.3.0-M2 installed within Eclipse
> Jboss AS 7.0.0.CR1 running using 64 bit JVM from Dos using unmodified standalone.bat
> Also when started via Eclipse server runtime.
>            Reporter: Gerry Matte
>              Labels: class, jndi, loader, naming, properties
>         Attachments: eclipse-as7.log, jndiTests.war.zip, jndiTests.zip, readme.txt
>
>
> Web applications on JBoss AS 6 and earlier could use the class loader to find and load a properties file stored in WEB/lib
> Jboss 7 seems to not find the properties file.
> Until now I believed that this folder was considered to be part of the classpath for a webapp.  Perhaps it is not ?
> I will attach a test eclipse project and a war file either to this bug report or to the forum posting.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 17:26:23 2011
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Tue, 5 Jul 2011 17:26:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1192) Classloader
 Thread.currentThread().getContextClassLoader() no longer inspects
 WEB-INF/lib
In-Reply-To: <1360489738.36304.1309900943699.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1632024185.36316.1309901183726.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

SBS JIRA Integration updated AS7-1192:
--------------------------------------

    Forum Reference: http://community.jboss.org/message/613328#613328, http://community.jboss.org/message/613361#613361  (was: http://community.jboss.org/message/613361#613361)


> Classloader Thread.currentThread().getContextClassLoader() no longer inspects WEB-INF/lib
> -----------------------------------------------------------------------------------------
>
>                 Key: AS7-1192
>                 URL: https://issues.jboss.org/browse/AS7-1192
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Naming, Web
>    Affects Versions: 7.0.0.CR1
>         Environment: Windows 7 64 bit with java 1.6 U24 installed (both 64 bit - default version) and with 32 bit installed.
> Eclipse Indigo 32 bit running with 32 bit jvm by using command line option  -vm C:\s\java32\bin\javaw.exe
> JBoss Tools 3.3.0-M2 installed within Eclipse
> Jboss AS 7.0.0.CR1 running using 64 bit JVM from Dos using unmodified standalone.bat
> Also when started via Eclipse server runtime.
>            Reporter: Gerry Matte
>              Labels: class, jndi, loader, naming, properties
>         Attachments: eclipse-as7.log, jndiTests.war.zip, jndiTests.zip, readme.txt
>
>
> Web applications on JBoss AS 6 and earlier could use the class loader to find and load a properties file stored in WEB/lib
> Jboss 7 seems to not find the properties file.
> Until now I believed that this folder was considered to be part of the classpath for a webapp.  Perhaps it is not ?
> I will attach a test eclipse project and a war file either to this bug report or to the forum posting.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 18:00:24 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 5 Jul 2011 18:00:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1192) Classloader
 Thread.currentThread().getContextClassLoader() no longer inspects
 WEB-INF/lib
In-Reply-To: <1360489738.36304.1309900943699.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1971693614.36403.1309903224235.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd resolved AS7-1192.
------------------------------

    Resolution: Won't Fix


No, by spec {{WEB-INF/lib}} is not a class path root.  You can put your file in a JAR in {{WEB-INF/lib}} or directly in {{WEB-INF/classes}} if you want.

> Classloader Thread.currentThread().getContextClassLoader() no longer inspects WEB-INF/lib
> -----------------------------------------------------------------------------------------
>
>                 Key: AS7-1192
>                 URL: https://issues.jboss.org/browse/AS7-1192
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Naming, Web
>    Affects Versions: 7.0.0.CR1
>         Environment: Windows 7 64 bit with java 1.6 U24 installed (both 64 bit - default version) and with 32 bit installed.
> Eclipse Indigo 32 bit running with 32 bit jvm by using command line option  -vm C:\s\java32\bin\javaw.exe
> JBoss Tools 3.3.0-M2 installed within Eclipse
> Jboss AS 7.0.0.CR1 running using 64 bit JVM from Dos using unmodified standalone.bat
> Also when started via Eclipse server runtime.
>            Reporter: Gerry Matte
>              Labels: class, jndi, loader, naming, properties
>         Attachments: eclipse-as7.log, jndiTests.war.zip, jndiTests.zip, readme.txt
>
>
> Web applications on JBoss AS 6 and earlier could use the class loader to find and load a properties file stored in WEB/lib
> Jboss 7 seems to not find the properties file.
> Until now I believed that this folder was considered to be part of the classpath for a webapp.  Perhaps it is not ?
> I will attach a test eclipse project and a war file either to this bug report or to the forum posting.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 18:43:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 5 Jul 2011 18:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1193) mod_cluster advertise
 listener not registering correct bind address
Message-ID: <835473738.36437.1309905803622.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

mod_cluster advertise listener not registering correct bind address
-------------------------------------------------------------------

                 Key: AS7-1193
                 URL: https://issues.jboss.org/browse/AS7-1193
             Project: Application Server 7
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 7.0.0.CR1
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
            Priority: Critical
             Fix For: 7.0.0.Final




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 19:07:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 5 Jul 2011 19:07:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1194) CDI interceptor order
 is wrong when method level interceptors are used
Message-ID: <645249168.36446.1309907243613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

CDI interceptor order is wrong when method level interceptors are used
----------------------------------------------------------------------

                 Key: AS7-1194
                 URL: https://issues.jboss.org/browse/AS7-1194
             Project: Application Server 7
          Issue Type: Bug
          Components: CDI / Weld
    Affects Versions: 7.0.0.CR1
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas
             Fix For: 7.0.1.Final


CDI interceptors are being run before method level @Interceptors interceptors

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 19:45:24 2011
From: jira-events at lists.jboss.org (Bruno Vernay (JIRA))
Date: Tue, 5 Jul 2011 19:45:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1195) Failure to load
 login-module should be reported as WARNING instead of TRACE
Message-ID: <604271086.36476.1309909524203.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Failure to load login-module should be reported as WARNING instead of TRACE
---------------------------------------------------------------------------

                 Key: AS7-1195
                 URL: https://issues.jboss.org/browse/AS7-1195
             Project: Application Server 7
          Issue Type: Feature Request
          Components: Security
    Affects Versions: 7.0.0.CR1
         Environment: java-6-sun-1.6.0.24
Linux ubuntu 
            Reporter: Bruno Vernay


An error in standalone.xml :
<security-domains>              
 <security-domain ...>
  <authentication>
   <login-module code="database" flag="required">

is reported in TRACE: 

TRACE [org.jboss.security.authentication.JBossCachedAuthenticationManager] (http--127.0.0.1-8080-1) Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: database from [Module "deployment.jboss-as-login.war:main" from Service Module Loader]

It makes it difficult to spot the error. 
Would be easier if it was reported as a WARNING, specially since it is "required"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 19:45:25 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 5 Jul 2011 19:45:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBLOGGING-54) MDC entries do
 not appear in jboss log
In-Reply-To: <1765512589.18536.1296817599423.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <182033800.36493.1309909525215.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd resolved JBLOGGING-54.
----------------------------------

    Resolution: Done


Should be fixed now.

> MDC entries do not appear in jboss log
> --------------------------------------
>
>                 Key: JBLOGGING-54
>                 URL: https://issues.jboss.org/browse/JBLOGGING-54
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logging-spi
>    Affects Versions: 3.0.0.Beta4-jboss-logging
>         Environment: 64bit Linux, JDK1.6.0_23
>            Reporter: Chris Jansen
>            Assignee: David Lloyd
>             Fix For: 3.0.0.GA
>
>
> As per title, MDC entries do not appear in jboss log when using the log pattern "%d %-5p [%c] (%t) [%X{user} %X{task}] - %s%E%n"?????

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Tue Jul  5 19:45:25 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 5 Jul 2011 19:45:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBLOGGING-58) Support setting
 the logging provider explicitly
In-Reply-To: <435989102.40315.1300731349870.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1105947963.36498.1309909525375.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd updated JBLOGGING-58:
---------------------------------

    Fix Version/s: 3.1.0.Beta1
                       (was: 3.0.0.GA)


> Support setting the logging provider explicitly
> -----------------------------------------------
>
>                 Key: JBLOGGING-58
>                 URL: https://issues.jboss.org/browse/JBLOGGING-58
>             Project: JBoss Logging
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.0.0.Beta4-jboss-logging
>            Reporter: Dan Allen
>            Assignee: David Lloyd
>            Priority: Minor
>             Fix For: 3.1.0.Beta1
>
>
> Currently, JBoss Logging uses a classloading approach to look for a logging provider based on a hardcoded order of precedence. While this is sufficient for the default case, there should be a way to specify the logger explicitly, in the case that there is more than one concrete logging implementation on the classpath.
> The override should be part of the API, though a system property could also be supported. The API would take precedence.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 19:45:25 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 5 Jul 2011 19:45:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBLOGGING-52) Use of system
 property for proxy generation setting is too inflexible
In-Reply-To: <262807505.17787.1292957778309.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2116251464.36504.1309909525639.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd updated JBLOGGING-52:
---------------------------------

    Fix Version/s: 3.1.0.Beta1
                       (was: 3.0.0.GA)


> Use of system property for proxy generation setting is too inflexible
> ---------------------------------------------------------------------
>
>                 Key: JBLOGGING-52
>                 URL: https://issues.jboss.org/browse/JBLOGGING-52
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jboss-logging-spi
>    Affects Versions: 3.0.0.Beta4-jboss-logging
>            Reporter: Dan Allen
>            Assignee: Dan Allen
>             Fix For: 3.1.0.Beta1
>
>
> JBoss Logging uses a system property to configure whether or not proxies are generated for type-safe loggers. This approach is very inflexible.
> The main issue is that the value of this system property is being cached too aggressively. In CDI extensions, we are forced to use a static code block to set the property so it is assigned early enough that JBoss Logging caches the correct value. However, with multiple extensions loading in a non-deterministic order, we end up having to put this static block in multiple places. [1]
> We need a better way to apply this setting. Perhaps a static method on a configuration API to assign the value before any logging takes place. 
> [1] https://github.com/seam/solder/blob/master/impl/src/main/java/org/jboss/seam/solder/log/LoggerExtension.java
> https://github.com/seam/servlet/blob/master/impl/src/main/java/org/jboss/seam/servlet/ServletExtension.java 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 19:45:25 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 5 Jul 2011 19:45:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBLOGGING-43) Provide the
 ability to pull jboss-logging into a project's package space via maven
In-Reply-To: <905186140.1270499977709.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <364362788.36508.1309909525815.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd updated JBLOGGING-43:
---------------------------------

    Fix Version/s: 3.1.0.Beta1
                       (was: 3.0.0.GA)


> Provide the ability to pull jboss-logging into a project's package space via maven
> ----------------------------------------------------------------------------------
>
>                 Key: JBLOGGING-43
>                 URL: https://issues.jboss.org/browse/JBLOGGING-43
>             Project: JBoss Logging
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 3.1.0.Beta1
>
>
> Via shade plugin perhaps, in order to avoid requiring an explicit dep for users on jboss-logging.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 19:45:25 2011
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Tue, 5 Jul 2011 19:45:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1195) Failure to load
 login-module should be reported as WARNING instead of TRACE
In-Reply-To: <604271086.36476.1309909524203.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <594071813.36511.1309909525889.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

SBS JIRA Integration updated AS7-1195:
--------------------------------------

    Forum Reference: http://community.jboss.org/message/613349#613349, http://community.jboss.org/message/613587#613587  (was: http://community.jboss.org/message/613587#613587)


> Failure to load login-module should be reported as WARNING instead of TRACE
> ---------------------------------------------------------------------------
>
>                 Key: AS7-1195
>                 URL: https://issues.jboss.org/browse/AS7-1195
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Security
>    Affects Versions: 7.0.0.CR1
>         Environment: java-6-sun-1.6.0.24
> Linux ubuntu 
>            Reporter: Bruno Vernay
>
> An error in standalone.xml :
> <security-domains>              
>  <security-domain ...>
>   <authentication>
>    <login-module code="database" flag="required">
> is reported in TRACE: 
> TRACE [org.jboss.security.authentication.JBossCachedAuthenticationManager] (http--127.0.0.1-8080-1) Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: database from [Module "deployment.jboss-as-login.war:main" from Service Module Loader]
> It makes it difficult to spot the error. 
> Would be easier if it was reported as a WARNING, specially since it is "required"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 20:09:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 5 Jul 2011 20:09:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1170) support
 configuration of number of virtual nodes
In-Reply-To: <230656898.32098.1309522704621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <165510587.36546.1309910963908.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro resolved AS7-1170.
-------------------------------

    Resolution: Done


To configure the number of virtual nodes:
<distributed-cache virtual-nodes="1"/>

> support configuration of number of virtual nodes
> ------------------------------------------------
>
>                 Key: AS7-1170
>                 URL: https://issues.jboss.org/browse/AS7-1170
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 7.0.0.CR1
>            Reporter: Michal Linhard
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 7.0.0.Final
>
>
> I recently played with consistent hash function implementation and produced various performance statistics.
> It shows that number of virtual nodes (configuration parameter I98 in https://docspace.corp.redhat.com/docs/DOC-69249) has substantial effect on performance. (it makes distribution of data among nodes in the cluster much more even and thus avoids overstressing of one particular node, that would then hinder performance of the whole cluster)
> If the next EDG6 Alpha build will take configuration from infinispan subsystem, we'll need to have this configurable, otherwise we won't be able to execute some very important performance comparisons.
> it applies to the level of subsystem.cache-container.distributed-cache
> so I propose addition of configuration parameter:
> subsystem.cache-container.distributed-cache.numVirtualNodes that would have the same effect as I98 infinispan.configuration.clustering.hash.numVirtualNodes

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 20:11:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 5 Jul 2011 20:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1147) Need to verify
 during deploy that web session cache is configured with invocation batching
In-Reply-To: <265137729.28829.1309392023774.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <697340071.36552.1309911083863.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro resolved AS7-1147.
-------------------------------

    Resolution: Done


> Need to verify during deploy that web session cache is configured with invocation batching
> ------------------------------------------------------------------------------------------
>
>                 Key: AS7-1147
>                 URL: https://issues.jboss.org/browse/AS7-1147
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.CR1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 7.0.0.Final
>
>
> Currently, there is no such check, and the user ends up getting errors during runtime.  Instead, this should be checked at deploy time, in call to DistributedCacheManagerFactory.getDistributedCacheManager(...).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 20:11:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 5 Jul 2011 20:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1175) Upgrade Infinispan
	to 5.0.0.CR7
In-Reply-To: <1350022527.32874.1309653803636.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <967191488.36555.1309911083946.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro resolved AS7-1175.
-------------------------------

    Resolution: Done


> Upgrade Infinispan to 5.0.0.CR7
> -------------------------------
>
>                 Key: AS7-1175
>                 URL: https://issues.jboss.org/browse/AS7-1175
>             Project: Application Server 7
>          Issue Type: Component  Upgrade
>          Components: Clustering
>    Affects Versions: 7.0.0.CR1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 7.0.0.Final
>
>
> Contains yet another minor API change affecting EvictionListeners

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 22:40:23 2011
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Tue, 5 Jul 2011 22:40:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-1193) mod_cluster advertise
 listener not registering correct bind address
In-Reply-To: <835473738.36437.1309905803622.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1380814362.36642.1309920023626.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jason Greene closed AS7-1193.
-----------------------------

    Resolution: Done


> mod_cluster advertise listener not registering correct bind address
> -------------------------------------------------------------------
>
>                 Key: AS7-1193
>                 URL: https://issues.jboss.org/browse/AS7-1193
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.CR1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 7.0.0.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 22:42:23 2011
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Tue, 5 Jul 2011 22:42:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-1191) Cache listener events
 in DistributedCacheManager throwing CNFEs during Event.getKey()
In-Reply-To: <1763090635.36156.1309896563659.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1850863997.36647.1309920143660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jason Greene closed AS7-1191.
-----------------------------

    Resolution: Done


> Cache listener events in DistributedCacheManager throwing CNFEs during Event.getKey()
> -------------------------------------------------------------------------------------
>
>                 Key: AS7-1191
>                 URL: https://issues.jboss.org/browse/AS7-1191
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.CR1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>            Priority: Blocker
>             Fix For: 7.0.0.Final
>
>
> Because we're using a custom key to store web sessions, Event.getKey() needs to deserialize key using the correct classloader.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 22:42:23 2011
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Tue, 5 Jul 2011 22:42:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-1161) --commands argument
 for help command
In-Reply-To: <200401603.30270.1309449083854.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1834995011.36648.1309920143686.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jason Greene closed AS7-1161.
-----------------------------

    Resolution: Done


> --commands argument for help command
> ------------------------------------
>
>                 Key: AS7-1161
>                 URL: https://issues.jboss.org/browse/AS7-1161
>             Project: Application Server 7
>          Issue Type: Task
>          Components: CLI
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 7.0.0.Final
>
>
> It would be nice to be able to list the commands available in the current CLI context using help command (which actually is equivalent to the tab-completion).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 22:45:23 2011
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Tue, 5 Jul 2011 22:45:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-1173) 'transformers' element
 not declared in jboss-deployment-structure-1_0.xsd
In-Reply-To: <811986275.32827.1309622663611.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <518375355.36655.1309920323946.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jason Greene closed AS7-1173.
-----------------------------

    Resolution: Done


> 'transformers' element not declared in jboss-deployment-structure-1_0.xsd
> -------------------------------------------------------------------------
>
>                 Key: AS7-1173
>                 URL: https://issues.jboss.org/browse/AS7-1173
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.CR1
>            Reporter: Marius Bogoevici
>            Assignee: Marius Bogoevici
>             Fix For: 7.0.0.Final
>
>
> The 'transformers' element is not declared as part of the 'deploymentType' type.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 22:45:24 2011
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Tue, 5 Jul 2011 22:45:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1171) relative names that
 start with "java:XXX", XXX must be: "comp", "module", "app", "global",
 "jboss"
In-Reply-To: <2124232099.32265.1309525703692.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1919820341.36658.1309920324085.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jason Greene updated AS7-1171:
------------------------------

      Fix Version/s: 7.0.1.Final
                         (was: 7.0.0.Final)
    Forum Reference: http://community.jboss.org/message/612948, http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/thread.html#2879  (was: http://community.jboss.org/message/612948, http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/thread.html#2879)


> relative names that start with "java:XXX", XXX must be: "comp", "module", "app", "global","jboss"
> -------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1171
>                 URL: https://issues.jboss.org/browse/AS7-1171
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 7.0.0.CR1
>            Reporter: Scott Marlow
>            Assignee: John Bailey
>             Fix For: 7.0.1.Final
>
>
> Using a datasource name like "java:jdbc/eFpDataSource" in a persistence.xml doesn't seem to work.  We seem to start to deploy the datasource but cannot resolve the service lookup.
> Deploying an application that contains a persistence unit reference to the above datasource (see forum post for efp.ear zip), leads to the following server.log output:
> 07:20:11,374 DEBUG [org.jboss.as.connector.deployer.dsdeployer] (MSC service thread 1-1) Adding datasource: java:/java:jdbc/eFpDataSource
> 07:20:11,378 TRACE [org.jboss.as.naming.service.BinderService] (MSC service thread 1-2) Bound resource jdbc/eFpDataSource into naming store org.jboss.as.naming.InMemoryNamingStore at 65499154
> And the application (includes persistence.xml reference to EfpDataSource) fails to deploy, with the following:
>    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.java:jdbc/eFpDataSource (missing)
> Instead, we should get a naming ("invalid name") exception when the datasource is added.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 23:19:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 5 Jul 2011 23:19:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1196) NPE during session
 ownership acquisition on failover.
Message-ID: <1710949728.36674.1309922363762.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

NPE during session ownership acquisition on failover.
-----------------------------------------------------

                 Key: AS7-1196
                 URL: https://issues.jboss.org/browse/AS7-1196
             Project: Application Server 7
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 7.0.0.CR1
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
            Priority: Critical
             Fix For: 7.0.0.Final


Since migration to complex key for sessions, session ownership logic needs to lock on simple key, since they will be deserialized eagerly.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul  5 23:55:27 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 5 Jul 2011 23:55:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1196) NPE during session
 ownership acquisition on failover.
In-Reply-To: <1710949728.36674.1309922363762.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <901471868.36736.1309924527632.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro updated AS7-1196:
------------------------------

    Description: Since migration to complex key for sessions, session ownership logic needs to lock on simple key, since they will be deserialized eagerly, while still allowing CoreGroupCommunicationService to deserialize its own rpc objects.  (was: Since migration to complex key for sessions, session ownership logic needs to lock on simple key, since they will be deserialized eagerly.)


> NPE during session ownership acquisition on failover.
> -----------------------------------------------------
>
>                 Key: AS7-1196
>                 URL: https://issues.jboss.org/browse/AS7-1196
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.CR1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 7.0.0.Final
>
>
> Since migration to complex key for sessions, session ownership logic needs to lock on simple key, since they will be deserialized eagerly, while still allowing CoreGroupCommunicationService to deserialize its own rpc objects.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 01:37:24 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Wed, 6 Jul 2011 01:37:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1844) JBM throws
 "No expiry queue has been specified so the message will be removed"
In-Reply-To: <1217451594.37497.1296023629693.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1349204278.36852.1309930644456.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao updated JBMESSAGING-1844:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP14
                       (was: Unscheduled)


> JBM throws "No expiry queue has been specified so the message will be removed"
> ------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1844
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1844
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Distributed Support
>    Affects Versions: 1.4.0.SP3.CP10
>         Environment: JBoss-EAP-4.3_CP8, JBM-1.4.0-SP3_CP10
>            Reporter: Tyronne Wickramarathne
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP14
>
>
> Clustered JBM throws "No expiry queue has been specified so the message will be removed" WARN message

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 02:02:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Wed, 6 Jul 2011 02:02:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1194) CDI interceptor
 order is wrong when method level interceptors are used
In-Reply-To: <645249168.36446.1309907243613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1555349993.36872.1309932143661.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved AS7-1194.
---------------------------------

    Fix Version/s: 7.0.0.Final
                       (was: 7.0.1.Final)
       Resolution: Done


> CDI interceptor order is wrong when method level interceptors are used
> ----------------------------------------------------------------------
>
>                 Key: AS7-1194
>                 URL: https://issues.jboss.org/browse/AS7-1194
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 7.0.0.CR1
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 7.0.0.Final
>
>
> CDI interceptors are being run before method level @Interceptors interceptors

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 02:09:23 2011
From: jira-events at lists.jboss.org (Jason Porter (JIRA))
Date: Wed, 6 Jul 2011 02:09:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1197) Create a
 DeploymentException and wrap deployment errors with that instead of
 java.lang.Exception
Message-ID: <124487309.36875.1309932563631.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Create a DeploymentException and wrap deployment errors with that instead of java.lang.Exception
------------------------------------------------------------------------------------------------

                 Key: AS7-1197
                 URL: https://issues.jboss.org/browse/AS7-1197
             Project: Application Server 7
          Issue Type: Enhancement
    Affects Versions: 7.0.0.CR1
            Reporter: Jason Porter
            Priority: Minor


You can see the exception here:


-------------------------------------------------------------------------------
Test set: org.jboss.seam.exception.control.test.extension.ExtensionErrorTest
-------------------------------------------------------------------------------
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.711 sec <<< FAILURE!
org.jboss.seam.exception.control.test.extension.ExtensionErrorTest  Time elapsed: 0 sec  <<< ERROR!
org.jboss.arquillian.container.spi.client.container.DeploymentException: Could not deploy to container
	at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:58)
	at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:111)
	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:148)
	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:115)
	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:246)
	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.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.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.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
	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.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
	at sun.reflect.GeneratedMethodAccessor6.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.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
	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.proceed(EventContextImpl.java:88)
	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.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:86)
	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:79)
	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:238)
	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:222)
	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:78)
	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.client.ContainerEventController.execute(ContainerEventController.java:97)
	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.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:68)
	at sun.reflect.GeneratedMethodAccessor4.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:54)
	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.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80)
	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:158)
	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:290)
	at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:45)
	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:175)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:123)
	at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
	at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:120)
	at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:103)
	at org.apache.maven.surefire.Surefire.run(Surefire.java:169)
	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.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350)
	at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021)
Caused by: java.lang.Exception: {
    "Failed services" => {"jboss.deployment.unit.\"extensionError.war\".WeldService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"extensionError.war\".WeldService: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
Exception 0 :
java.lang.IllegalArgumentException: Handler method public void org.jboss.seam.exception.control.test.handler.HandlerWhichThrowsExceptions.throwsAnException(org.jboss.seam.exception.control.CaughtException) throws java.lang.Exception must not throw exceptions
	at org.jboss.seam.exception.control.extension.CatchExtension.findHandlers(CatchExtension.java:93)
	at sun.reflect.GeneratedMethodAccessor413.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
	at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
	at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
	at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
	at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
	at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
	at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
	at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:282)
	at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:265)
	at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234)
	at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:632)
	at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:619)
	at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:67)
	at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:42)
	at org.jboss.weld.bootstrap.events.ProcessManagedBeanImpl.fire(ProcessManagedBeanImpl.java:34)
	at org.jboss.weld.bootstrap.AbstractBeanDeployer.deploy(AbstractBeanDeployer.java:126)
	at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:216)
	at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:370)
	at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:81)
	at org.jboss.as.weld.services.WeldService.start(WeldService.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)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:662)
"},
    "Services with missing/unavailable dependencies" => [
        "jboss.deployment.unit.\"extensionError.war\".component.\"org.jboss.seam.solder.resourceLoader.servlet.ResourceListener\".WeldInstantiator",
        "jboss.deployment.unit.\"extensionError.war\".jndiDependencyService",
        "jboss.deployment.unit.\"extensionError.war\".component.\"org.jboss.as.weld.webtier.jsp.JspInitializationListener\".START",
        "jboss.web.\"extensionError.war\"",
        "jboss.naming.context.java.module.extensionError.extensionError.BeanManager",
        "jboss.deployment.unit.\"extensionError.war\".component.\"org.jboss.seam.solder.resourceLoader.servlet.ResourceListener\".START",
        "jboss.deployment.unit.\"extensionError.war\".beanmanager",
        "jboss.deployment.unit.\"extensionError.war\".component.\"org.jboss.as.weld.webtier.jsp.JspInitializationListener\".WeldInstantiator"
    ]
}
	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:99)
	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:88)
	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:70)
	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42)
	at org.jboss.as.arquillian.container.ArchiveDeployer.executeDeploymentPlan(ArchiveDeployer.java:75)
	at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:56)
	... 88 more


The exception I'm expecting is the DefinitionException, not java.lang.Exception. Understandably it may not be correct to pass back the actual exception without wrapping it, but wrapping in java.lang.Exception doesn't really cut it either.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 02:13:23 2011
From: jira-events at lists.jboss.org (Andrew Rubinger (JIRA))
Date: Wed, 6 Jul 2011 02:13:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-650) Create POM and
 Assembly for AS7 Public APIs
In-Reply-To: <1476137624.18036.1302521313100.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1363498272.36878.1309932803801.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Andrew Rubinger resolved AS7-650.
---------------------------------

    Fix Version/s: 7.0.0.Final
                       (was: 7.1.0.Alpha1)
       Resolution: Done


Upstream: https://github.com/jbossas/jboss-as/compare/7de35ea...7a8580c

Along with a separate POM to export out the EE APIs.

> Create POM and Assembly for AS7 Public APIs
> -------------------------------------------
>
>                 Key: AS7-650
>                 URL: https://issues.jboss.org/browse/AS7-650
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Build System
>            Reporter: Andrew Rubinger
>            Assignee: Andrew Rubinger
>             Fix For: 7.0.0.Final
>
>
> These to encompass all user-facing APIs in one shared artifact and POM.  First we must determine where these are independently housed, then reassemble for easy consumption both from Maven and as a straight dependency.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 02:27:23 2011
From: jira-events at lists.jboss.org (Jason Porter (JIRA))
Date: Wed, 6 Jul 2011 02:27:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1198) Add a Deployment
 Exception Transformer for the Arquillian container
Message-ID: <1317835349.36898.1309933643625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Add a Deployment Exception Transformer for the Arquillian container
-------------------------------------------------------------------

                 Key: AS7-1198
                 URL: https://issues.jboss.org/browse/AS7-1198
             Project: Application Server 7
          Issue Type: Feature Request
            Reporter: Jason Porter


A discussion on IRC: http://echelog.matzon.dk/logs/browse/jbosstesting/1309903200

We're not reporting back to ARQ users the actual error during deployment, just whatever the app server gives us.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 02:50:23 2011
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Wed, 6 Jul 2011 02:50:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-205) Invalid async
 context for servlet: Atmosphere Async Servlet on JBoss Web
In-Reply-To: <1369266963.32802.1309619303616.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2098044558.36912.1309935023792.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Remy Maucherat commented on JBWEB-205:
--------------------------------------

No, the TCK works fine. It is expected the bug also occurs with AS 6, since the code is the same. The test case has apparent thread related issues, so this could ultimately be caused by that.

AS 7.0 GA will have web 7.0 CR 4 (no time to test a new build properly), new builds will go into the maintenance releases.

> Invalid async context for servlet: Atmosphere Async  Servlet on JBoss Web
> -------------------------------------------------------------------------
>
>                 Key: JBWEB-205
>                 URL: https://issues.jboss.org/browse/JBWEB-205
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-7.0.0.CR1
>         Environment: Firefox 4.0.1 / Chromium 12 
> AS 6.0.0.Final / 6.1.0-SNAPSHOT / AS 7.0.0.CR1 
> Atmosphere 0.7.1/0.7.2 
>            Reporter: Luk?? Fry?
>            Assignee: Remy Maucherat
>            Priority: Critical
>             Fix For: JBossWeb-7.0.1.GA 
>
>         Attachments: push-jms.war
>
>
> Source of sample for reproduction:
> https://github.com/lfryc/push-jms/commit/9cee160570e049ca4783e1fcbdac25ffef1b10b7
> {code}
> 16:08:28,467 ERROR [org.apache.catalina.connector.CoyoteAdapter] (http-localhost-127.0.0.1-8080-7) An exception or error occurred in the container during the request processing: java.lang.IllegalStateException: Invalid async context for servlet AutoRegisteredPushServlet
> 	at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:643) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:402) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:183) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:246) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ValveBase.event(ValveBase.java:193) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:128) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:265) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11Processor.event(Http11Processor.java:757) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.event(Http11Protocol.java:615) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:938) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at java.lang.Thread.run(Thread.java:636) [:1.6.0_20]
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Wed Jul  6 03:02:23 2011
From: jira-events at lists.jboss.org (Lin Gao (JIRA))
Date: Wed, 6 Jul 2011 03:02:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-611) Adds support of brew
	build
Message-ID: <2014129994.36919.1309935743671.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Adds support of brew build
--------------------------

                 Key: JBJCA-611
                 URL: https://issues.jboss.org/browse/JBJCA-611
             Project: IronJacamar
          Issue Type: Task
          Components: Build
            Reporter: Lin Gao
            Assignee: Lin Gao




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 03:04:23 2011
From: jira-events at lists.jboss.org (Jason Porter (JIRA))
Date: Wed, 6 Jul 2011 03:04:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1197) Create a
 DeploymentException and wrap deployment errors with that instead of
 java.lang.Exception
In-Reply-To: <124487309.36875.1309932563631.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1540817041.36921.1309935863640.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jason Porter commented on AS7-1197:
-----------------------------------

We're not actually wrapping the exception in controller-client/src/main/java/org/jboss/as/controller/client/helpers/standalone/impl/ServerDeploymentPlanResultFuture.java line 99.

We simply create a new exception with the message of exception instead of wrapping it.

> Create a DeploymentException and wrap deployment errors with that instead of java.lang.Exception
> ------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1197
>                 URL: https://issues.jboss.org/browse/AS7-1197
>             Project: Application Server 7
>          Issue Type: Enhancement
>    Affects Versions: 7.0.0.CR1
>            Reporter: Jason Porter
>            Priority: Minor
>
> You can see the exception here:
> -------------------------------------------------------------------------------
> Test set: org.jboss.seam.exception.control.test.extension.ExtensionErrorTest
> -------------------------------------------------------------------------------
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.711 sec <<< FAILURE!
> org.jboss.seam.exception.control.test.extension.ExtensionErrorTest  Time elapsed: 0 sec  <<< ERROR!
> org.jboss.arquillian.container.spi.client.container.DeploymentException: Could not deploy to container
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:58)
> 	at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:111)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:148)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:115)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:246)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.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.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.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
> 	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.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
> 	at sun.reflect.GeneratedMethodAccessor6.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.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
> 	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.proceed(EventContextImpl.java:88)
> 	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.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:86)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:79)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:238)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:222)
> 	at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:78)
> 	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.client.ContainerEventController.execute(ContainerEventController.java:97)
> 	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.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:68)
> 	at sun.reflect.GeneratedMethodAccessor4.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:54)
> 	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.core.impl.ManagerImpl.fire(ManagerImpl.java:134)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:158)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:290)
> 	at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:45)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:175)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:123)
> 	at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
> 	at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:120)
> 	at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:103)
> 	at org.apache.maven.surefire.Surefire.run(Surefire.java:169)
> 	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.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350)
> 	at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021)
> Caused by: java.lang.Exception: {
>     "Failed services" => {"jboss.deployment.unit.\"extensionError.war\".WeldService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"extensionError.war\".WeldService: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
> Exception 0 :
> java.lang.IllegalArgumentException: Handler method public void org.jboss.seam.exception.control.test.handler.HandlerWhichThrowsExceptions.throwsAnException(org.jboss.seam.exception.control.CaughtException) throws java.lang.Exception must not throw exceptions
> 	at org.jboss.seam.exception.control.extension.CatchExtension.findHandlers(CatchExtension.java:93)
> 	at sun.reflect.GeneratedMethodAccessor413.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
> 	at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
> 	at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
> 	at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
> 	at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
> 	at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
> 	at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
> 	at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:282)
> 	at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:265)
> 	at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234)
> 	at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:632)
> 	at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:619)
> 	at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:67)
> 	at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:42)
> 	at org.jboss.weld.bootstrap.events.ProcessManagedBeanImpl.fire(ProcessManagedBeanImpl.java:34)
> 	at org.jboss.weld.bootstrap.AbstractBeanDeployer.deploy(AbstractBeanDeployer.java:126)
> 	at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:216)
> 	at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:370)
> 	at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:81)
> 	at org.jboss.as.weld.services.WeldService.start(WeldService.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)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:662)
> "},
>     "Services with missing/unavailable dependencies" => [
>         "jboss.deployment.unit.\"extensionError.war\".component.\"org.jboss.seam.solder.resourceLoader.servlet.ResourceListener\".WeldInstantiator",
>         "jboss.deployment.unit.\"extensionError.war\".jndiDependencyService",
>         "jboss.deployment.unit.\"extensionError.war\".component.\"org.jboss.as.weld.webtier.jsp.JspInitializationListener\".START",
>         "jboss.web.\"extensionError.war\"",
>         "jboss.naming.context.java.module.extensionError.extensionError.BeanManager",
>         "jboss.deployment.unit.\"extensionError.war\".component.\"org.jboss.seam.solder.resourceLoader.servlet.ResourceListener\".START",
>         "jboss.deployment.unit.\"extensionError.war\".beanmanager",
>         "jboss.deployment.unit.\"extensionError.war\".component.\"org.jboss.as.weld.webtier.jsp.JspInitializationListener\".WeldInstantiator"
>     ]
> }
> 	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:99)
> 	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:88)
> 	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:70)
> 	at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.executeDeploymentPlan(ArchiveDeployer.java:75)
> 	at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:56)
> 	... 88 more
> The exception I'm expecting is the DefinitionException, not java.lang.Exception. Understandably it may not be correct to pass back the actual exception without wrapping it, but wrapping in java.lang.Exception doesn't really cut it either.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 03:45:23 2011
From: jira-events at lists.jboss.org (Lin Gao (JIRA))
Date: Wed, 6 Jul 2011 03:45:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-611) Adds support of
	brew build
In-Reply-To: <2014129994.36919.1309935743671.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2041853697.36953.1309938323940.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Lin Gao resolved JBJCA-611.
---------------------------

    Fix Version/s: 1.0.0.Final
       Resolution: Done


> Adds support of brew build
> --------------------------
>
>                 Key: JBJCA-611
>                 URL: https://issues.jboss.org/browse/JBJCA-611
>             Project: IronJacamar
>          Issue Type: Task
>          Components: Build
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>             Fix For: 1.0.0.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 05:23:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 6 Jul 2011 05:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (AS7-1199) Add OSGi Dynamic
 Services functionality
Message-ID: <2063342442.37061.1309944203712.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Thomas Diesler moved JBOSGI-475 to AS7-1199:
--------------------------------------------

          Project: Application Server 7  (was: JBoss OSGi)
              Key: AS7-1199  (was: JBOSGI-475)
         Workflow: GIT Pull Request workflow   (was: jira)
         Security:     (was: Public)
    Fix Version/s: 7.0.0.Final
                       (was:  JBossOSGi 1.0.0 CR1)


> Add OSGi Dynamic Services functionality
> ---------------------------------------
>
>                 Key: AS7-1199
>                 URL: https://issues.jboss.org/browse/AS7-1199
>             Project: Application Server 7
>          Issue Type: Feature Request
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For: 7.0.0.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 05:23:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 6 Jul 2011 05:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1199) Add OSGi Dynamic
 Services functionality
Message-ID: <1848421678.37062.1309944203775.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Thomas Diesler updated AS7-1199:
--------------------------------

    Component/s: OSGi


> Add OSGi Dynamic Services functionality
> ---------------------------------------
>
>                 Key: AS7-1199
>                 URL: https://issues.jboss.org/browse/AS7-1199
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: OSGi
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For: 7.0.0.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 07:51:23 2011
From: jira-events at lists.jboss.org (santhosh ganapathi (JIRA))
Date: Wed, 6 Jul 2011 07:51:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-9414) Run time exception
 in Jboss 6 - org.jboss.cache.CacheException:
 java.lang.reflect.InvocationTargetException
Message-ID: <1676472132.37210.1309953083660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Run time exception in Jboss 6 - org.jboss.cache.CacheException: java.lang.reflect.InvocationTargetException
-----------------------------------------------------------------------------------------------------------

                 Key: JBAS-9414
                 URL: https://issues.jboss.org/browse/JBAS-9414
             Project: Legacy JBoss Application Server 6 
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.0.Final
         Environment: Windows xp OS, Jboss 6 with JDK 1.6, Hibernate 3.2.0.
            Reporter: santhosh ganapathi


15:29:42,059 ERROR [STDERR] org.jboss.cache.CacheException: java.lang.reflect.InvocationTargetException
15:29:42,059 ERROR [STDERR]     at org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:148)
15:29:42,059 ERROR [STDERR]     at org.jboss.cache.factories.ComponentRegistry$PrioritizedMethod.invoke(ComponentRegistry.java:970)
15:29:42,059 ERROR [STDERR]     at org.jboss.cache.factories.ComponentRegistry.internalStart(ComponentRegistry.java:746)
15:29:42,059 ERROR [STDERR]     at org.jboss.cache.factories.ComponentRegistry.start(ComponentRegistry.java:610)
15:29:42,059 ERROR [STDERR]     at org.jboss.cache.invocation.CacheInvocationDelegate.start(CacheInvocationDelegate.java:355)
15:29:42,059 ERROR [STDERR]     at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:121)
15:29:42,059 ERROR [STDERR]     at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:72)
15:29:42,059 ERROR [STDERR]     at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:67)
15:29:42,059 ERROR [STDERR]     at com.csscorp.presentation.spinneret.server.HRMSShadesGeneratorImpl.extractSpinneretPanel(HRMSShadesGeneratorImpl.java:114)
15:29:42,059 ERROR [STDERR]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
15:29:42,059 ERROR [STDERR]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
15:29:42,059 ERROR [STDERR]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
15:29:42,059 ERROR [STDERR]     at java.lang.reflect.Method.invoke(Method.java:597)
15:29:42,059 ERROR [STDERR]     at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:569)
15:29:42,059 ERROR [STDERR]     at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:208)
15:29:42,074 ERROR [STDERR]     at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:248)
15:29:42,074 ERROR [STDERR]     at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
15:29:42,074 ERROR [STDERR]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
15:29:42,074 ERROR [STDERR]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
15:29:42,074 ERROR [STDERR]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324)
15:29:42,074 ERROR [STDERR]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242)
15:29:42,074 ERROR [STDERR]     at com.csscorp.business.filter.HRMSLoginFilter.doFilter(HRMSLoginFilter.java:55)
15:29:42,090 ERROR [STDERR]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274)
15:29:42,090 ERROR [STDERR]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242)
15:29:42,090 ERROR [STDERR]     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
15:29:42,090 ERROR [STDERR]     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
15:29:42,090 ERROR [STDERR]     at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:181)
15:29:42,090 ERROR [STDERR]     at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285)
15:29:42,090 ERROR [STDERR]     at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261)
15:29:42,090 ERROR [STDERR]     at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:88)
15:29:42,106 ERROR [STDERR]     at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:100)
15:29:42,106 ERROR [STDERR]     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
15:29:42,106 ERROR [STDERR]     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
15:29:42,106 ERROR [STDERR]     at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
15:29:42,106 ERROR [STDERR]     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
15:29:42,106 ERROR [STDERR]     at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53)
15:29:42,106 ERROR [STDERR]     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
15:29:42,121 ERROR [STDERR]     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
15:29:42,121 ERROR [STDERR]     at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:654)
15:29:42,121 ERROR [STDERR]     at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951)
15:29:42,121 ERROR [STDERR]     at java.lang.Thread.run(Thread.java:619)
15:29:42,121 ERROR [STDERR] Caused by: java.lang.reflect.InvocationTargetException
15:29:42,121 ERROR [STDERR]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
15:29:42,137 ERROR [STDERR]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
15:29:42,137 ERROR [STDERR]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
15:29:42,137 ERROR [STDERR]     at java.lang.reflect.Method.invoke(Method.java:597)
15:29:42,137 ERROR [STDERR]     at org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:144)
15:29:42,137 ERROR [STDERR]     ... 40 more
15:29:42,137 ERROR [STDERR] Caused by: java.lang.LinkageError: loader constraint violation: when resolving method "java.lang.management.ManagementFactory.getPlatformMBeanServer()Ljavax/management/MBeanServer;" the class loader (instance of org/jboss/classloader/spi/base/BaseClassLoader) of the current class, org/jboss/cache/jmx/JmxRegistrationManager, and the class loader (instance of <bootloader>) for resolved class, java/lang/management/ManagementFactory, have different Class objects for the type javax/management/MBeanServer used in the signature
15:29:42,137 ERROR [STDERR]     at org.jboss.cache.jmx.JmxRegistrationManager.<init>(JmxRegistrationManager.java:128)
15:29:42,153 ERROR [STDERR]     at org.jboss.cache.jmx.JmxRegistrationManager.<init>(JmxRegistrationManager.java:133)
15:29:42,153 ERROR [STDERR]     at org.jboss.cache.jmx.PlatformMBeanServerRegistration.registerToPlatformMBeanServer(PlatformMBeanServerRegistration.java:69)
15:29:42,153 ERROR [STDERR]     ... 45 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 08:17:24 2011
From: jira-events at lists.jboss.org (Shilpi Khariwal (JIRA))
Date: Wed, 6 Jul 2011 08:17:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-8408)
 java.lang.NoClassDefFoundError: com/rsa/cryptoj/c/di using JBoss 6.0.0.M3
In-Reply-To: <614915905.1349.1284397272297.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <791891050.37278.1309954644088.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Shilpi Khariwal commented on JBAS-8408:
---------------------------------------

Hi,

Is there any update on the fix date for this issue? If this issue is not resolved I can not make use of JSafe library.

Thanks,
Shilpi

> java.lang.NoClassDefFoundError: com/rsa/cryptoj/c/di using JBoss 6.0.0.M3
> -------------------------------------------------------------------------
>
>                 Key: JBAS-8408
>                 URL: https://issues.jboss.org/browse/JBAS-8408
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading
>    Affects Versions: 6.0.0.M3
>         Environment: JBoss 6.0.0.M3, Windows 2003 R2 SP2.
>            Reporter: Sasha Matison
>            Assignee: Scott Stark
>            Priority: Critical
>             Fix For: No Release
>
>         Attachments: cryptojfiles.JPG, sample[1].war.rename
>
>
> Our application uses RSA crypto-j version 4.1. When executing a transaction we get the following error:
> java.lang.NoClassDefFoundError: com/rsa/cryptoj/c/di
> Although the class is present in the jar file (see attached screenshot).
> A sample .war that reproduces the problem is attached.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 08:17:24 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Wed, 6 Jul 2011 08:17:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1200) test case for xa
 datasource persistence to xml
Message-ID: <688662445.37283.1309954644343.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

test case for xa datasource persistence to xml
----------------------------------------------

                 Key: AS7-1200
                 URL: https://issues.jboss.org/browse/AS7-1200
             Project: Application Server 7
          Issue Type: Sub-task
            Reporter: Stefano Maestri
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 08:21:23 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Wed, 6 Jul 2011 08:21:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1201) test for en/diable xa
	datasources
Message-ID: <628827184.37288.1309954883712.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

test for en/diable xa datasources
---------------------------------

                 Key: AS7-1201
                 URL: https://issues.jboss.org/browse/AS7-1201
             Project: Application Server 7
          Issue Type: Sub-task
          Components: Test Suite
            Reporter: Stefano Maestri
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 08:21:23 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Wed, 6 Jul 2011 08:21:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1202) test for enable
	datasource
Message-ID: <1282958622.37289.1309954883783.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

test for enable datasource
--------------------------

                 Key: AS7-1202
                 URL: https://issues.jboss.org/browse/AS7-1202
             Project: Application Server 7
          Issue Type: Sub-task
          Components: Test Suite
            Reporter: Stefano Maestri
            Assignee: Stefano Maestri
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 08:23:23 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Wed, 6 Jul 2011 08:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1203) test for missing
 xa-datasource properties
Message-ID: <1239715458.37294.1309955003698.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

test for missing xa-datasource properties
-----------------------------------------

                 Key: AS7-1203
                 URL: https://issues.jboss.org/browse/AS7-1203
             Project: Application Server 7
          Issue Type: Sub-task
          Components: Test Suite
            Reporter: Stefano Maestri
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 08:25:23 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Wed, 6 Jul 2011 08:25:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1204) test for properties
 exception sorter, valid & stale connection checkers aren't stored
Message-ID: <1958462756.37297.1309955123728.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

test for properties exception sorter, valid & stale connection checkers aren't stored
-------------------------------------------------------------------------------------

                 Key: AS7-1204
                 URL: https://issues.jboss.org/browse/AS7-1204
             Project: Application Server 7
          Issue Type: Sub-task
          Components: Test Suite
            Reporter: Stefano Maestri
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 08:27:24 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 6 Jul 2011 08:27:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1205) Remove URL handler
 warnings at startup
Message-ID: <230350046.37308.1309955244447.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Remove URL handler warnings at startup
--------------------------------------

                 Key: AS7-1205
                 URL: https://issues.jboss.org/browse/AS7-1205
             Project: Application Server 7
          Issue Type: Task
            Reporter: Thomas Diesler


14:01:59,833 WARN  [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-1) Unable to set the URLStreamHandlerFactory
14:01:59,834 WARN  [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-1) Unable to set the ContentHandlerFactory


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 08:29:23 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Wed, 6 Jul 2011 08:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1206) test for jndi binding
 isn't unbound during remove if jndi name and data-source name are different
Message-ID: <915284666.37316.1309955363700.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

test for jndi binding isn't unbound during remove if jndi name and data-source name are different
-------------------------------------------------------------------------------------------------

                 Key: AS7-1206
                 URL: https://issues.jboss.org/browse/AS7-1206
             Project: Application Server 7
          Issue Type: Sub-task
          Components: Test Suite
            Reporter: Stefano Maestri
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 08:31:23 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Wed, 6 Jul 2011 08:31:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1207) test for not
 persisted (xa)datasource properties
Message-ID: <458762522.37319.1309955483781.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

test for not persisted (xa)datasource properties
------------------------------------------------

                 Key: AS7-1207
                 URL: https://issues.jboss.org/browse/AS7-1207
             Project: Application Server 7
          Issue Type: Sub-task
          Components: Test Suite
            Reporter: Stefano Maestri
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 08:39:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 6 Jul 2011 08:39:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1195) Failure to load
 login-module should be reported as WARNING instead of TRACE
In-Reply-To: <604271086.36476.1309909524203.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <829613112.37355.1309955964224.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai reassigned AS7-1195:
---------------------------------

    Assignee: Marcus Moyses


Darran mentioned that Marcus is already looking into logging levels in security subsystem. Assigning this to Marcus.

> Failure to load login-module should be reported as WARNING instead of TRACE
> ---------------------------------------------------------------------------
>
>                 Key: AS7-1195
>                 URL: https://issues.jboss.org/browse/AS7-1195
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Security
>    Affects Versions: 7.0.0.CR1
>         Environment: java-6-sun-1.6.0.24
> Linux ubuntu 
>            Reporter: Bruno Vernay
>            Assignee: Marcus Moyses
>
> An error in standalone.xml :
> <security-domains>              
>  <security-domain ...>
>   <authentication>
>    <login-module code="database" flag="required">
> is reported in TRACE: 
> TRACE [org.jboss.security.authentication.JBossCachedAuthenticationManager] (http--127.0.0.1-8080-1) Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: database from [Module "deployment.jboss-as-login.war:main" from Service Module Loader]
> It makes it difficult to spot the error. 
> Would be easier if it was reported as a WARNING, specially since it is "required"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 08:56:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 6 Jul 2011 08:56:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1205) Remove URL handler
 warnings at startup
In-Reply-To: <230350046.37308.1309955244447.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <245030927.37381.1309956983622.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Thomas Diesler reassigned AS7-1205:
-----------------------------------

    Assignee: Thomas Diesler


> Remove URL handler warnings at startup
> --------------------------------------
>
>                 Key: AS7-1205
>                 URL: https://issues.jboss.org/browse/AS7-1205
>             Project: Application Server 7
>          Issue Type: Task
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>
> 14:01:59,833 WARN  [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-1) Unable to set the URLStreamHandlerFactory
> 14:01:59,834 WARN  [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-1) Unable to set the ContentHandlerFactory

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 09:04:30 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 6 Jul 2011 09:04:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1112) EJB annotation
 processing DUP fails to find annotations from classes belonging to jars in
 .ear/lib
In-Reply-To: <156975585.18957.1308907943649.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <755630798.37395.1309957470114.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai updated AS7-1112:
------------------------------

     Git Pull Request: https://github.com/jaikiran/jboss-as/tree/AS7-1112  (was: https://github.com/jaikiran/jboss-as/tree/AS7-1112)
    Affects Version/s: 7.0.0.CR1
      Forum Reference: http://community.jboss.org/message/611776#611776  (was: http://community.jboss.org/message/611776#611776)


> EJB annotation processing DUP fails to find annotations from classes belonging to jars in .ear/lib
> --------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1112
>                 URL: https://issues.jboss.org/browse/AS7-1112
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 7.0.0.CR1
>         Environment: AS7 upstream (June 24 2011)
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> Consider the following deployment:
> {code}
> .ear
> |
> |--- lib/lib.jar
> |
> |--- ejb.jar
> {code}
> If ejb.jar contains:
> {code}
> @Stateless
> public class MyBean implements SomeInterface {
> }
> {code}
> and the lib/lib.jar contains the interface:
> {code}
> @Remote
> public interface SomeInterface  {
> ...
> }
> {code}
> then the BusinessViewAnnotationProcessor complains about missing index for the SomeInterface class:
> {code}
> 09:05:28,739 WARN  [org.jboss.as.ejb3.deployment.processors.BusinessViewAnnotationProcessor] (MSC service thread 1-2) Could not read annotations on EJB interface blah.blah.SomeInterface
> {code}
> Please see the referenced forum thread for the details.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 09:18:28 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Wed, 6 Jul 2011 09:18:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1844) JBM throws
 "No expiry queue has been specified so the message will be removed"
In-Reply-To: <1217451594.37497.1296023629693.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <748736359.37411.1309958308124.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao updated JBMESSAGING-1844:
--------------------------------------

    Attachment: DistributedTopicExample.java
                TopicReceiver.java


> JBM throws "No expiry queue has been specified so the message will be removed"
> ------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1844
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1844
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Distributed Support
>    Affects Versions: 1.4.0.SP3.CP10
>         Environment: JBoss-EAP-4.3_CP8, JBM-1.4.0-SP3_CP10
>            Reporter: Tyronne Wickramarathne
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP14
>
>         Attachments: DistributedTopicExample.java, TopicReceiver.java
>
>
> Clustered JBM throws "No expiry queue has been specified so the message will be removed" WARN message

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 09:20:24 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Wed, 6 Jul 2011 09:20:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1844) JBM throws
 "No expiry queue has been specified so the message will be removed"
In-Reply-To: <1217451594.37497.1296023629693.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <761708068.37418.1309958424057.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao commented on JBMESSAGING-1844:
-------------------------------------------

Hi Tyronne,

I just managed to write a test and I couldn't reproduce the issue with it. I need you help to have a look at my test (I uploaded the source code) and see if there is anything wrong with it.

By the way I use the latest JBM on Branch_1_4. What I got is when I start the consumer to receive, I didn't receive any messages and there is no warning message coming out of either nodes.

Thanks
Howard


> JBM throws "No expiry queue has been specified so the message will be removed"
> ------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1844
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1844
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Distributed Support
>    Affects Versions: 1.4.0.SP3.CP10
>         Environment: JBoss-EAP-4.3_CP8, JBM-1.4.0-SP3_CP10
>            Reporter: Tyronne Wickramarathne
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP14
>
>         Attachments: DistributedTopicExample.java, TopicReceiver.java
>
>
> Clustered JBM throws "No expiry queue has been specified so the message will be removed" WARN message

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 09:32:23 2011
From: jira-events at lists.jboss.org (Bill Burke (JIRA))
Date: Wed, 6 Jul 2011 09:32:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1208) poor error message
 with type in logging
Message-ID: <512096716.37430.1309959143765.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

poor error message with type in logging
---------------------------------------

                 Key: AS7-1208
                 URL: https://issues.jboss.org/browse/AS7-1208
             Project: Application Server 7
          Issue Type: Quality Risk
            Reporter: Bill Burke
            Priority: Minor


I had a typo in logging config for standalone.xml  "TRACEy" instead of "TRACE"

I got the obscure message of:

09:26:08,720 WARN  [org.jboss.as.controller] Operation ("add") failed - address: ([
    ("subsystem" => "logging"),
    ("periodic-rotating-file-handler" => "FILE")
])



--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 09:34:23 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Wed, 6 Jul 2011 09:34:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1209) Xa-datasource:add
 requires a non-empty map "xa-data-source-properties",
 which is not documented
Message-ID: <1961762238.37434.1309959263624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Xa-datasource:add requires a non-empty map "xa-data-source-properties", which is not documented
-----------------------------------------------------------------------------------------------

                 Key: AS7-1209
                 URL: https://issues.jboss.org/browse/AS7-1209
             Project: Application Server 7
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 7.0.0.CR1
            Reporter: Heiko Rupp
            Assignee: Brian Stansberry


[domain at localhost:9999 subsystem=datasources] ./xa-data-source=xa-ds:read-operation-description(name=add)
does not list a (required) property "xa-data-source-properties", but when this is not provided, adding a xa-datasource fails and console shows

[Server:server-two] 15:25:52,983 WARN  [org.jboss.as.controller] (pool-1-thread-35) Operation ("add") failed - address: ([
[Server:server-two]     ("subsystem" => "datasources"),
[Server:server-two]     ("xa-data-source" => "postgres")
[Server:server-two] ]): java.lang.IllegalArgumentException

Adding an empty xa-data-source-properties map also makes the :add fail. It only works when this property is present and some (dummy!) values are given.

1) the requirement for this xa-da.. should be documented
2) it should be optional
3) an empty map should be allowed (if no xa-props are needed)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 09:53:23 2011
From: jira-events at lists.jboss.org (Sandeep T H (JIRA))
Date: Wed, 6 Jul 2011 09:53:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1343) JGroups 2.6.2 hangs
 during JChannel.connect
Message-ID: <219174054.37442.1309960403679.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

JGroups 2.6.2 hangs during JChannel.connect
-------------------------------------------

                 Key: JGRP-1343
                 URL: https://issues.jboss.org/browse/JGRP-1343
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.6.2
         Environment: Linux, cluster
            Reporter: Sandeep T H
            Assignee: Bela Ban


In a cluster having two nodes A & B, A is up and running and when B is started for the first time it sometimes hangs in JChannel.connect.
If we bring down A then B is able to resume and connect. This issue happens randomly but frequently.
Please let us know if we have missed something or need something.
The jgroups configuration used is :
<config>
    <UDP
         mcast_addr="${jgroups.udp.mcast_addr:224.0.0.0}"
         mcast_port="${jgroups.udp.mcast_port:$JGroup_port}"
         tos="8"
         ucast_recv_buf_size="20000000"
         ucast_send_buf_size="640000"
         mcast_recv_buf_size="25000000"
         mcast_send_buf_size="640000"
         loopback="false"
         discard_incompatible_packets="true"
         max_bundle_size="64000"
         max_bundle_timeout="30"
         use_incoming_packet_handler="true"
         ip_ttl="${jgroups.udp.ip_ttl:2}"
         enable_bundling="true"
         enable_diagnostics="true"
         thread_naming_pattern="cl"

         use_concurrent_stack="true"

         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="1000"
         thread_pool.rejection_policy="Run"

         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="Run"/>

    <PING timeout="2000"
            num_initial_members="3"/>
    <MERGE2 max_interval="30000"
            min_interval="10000"/>
    <FD_SOCK/>
    <FD timeout="10000" max_tries="5"   shun="true"/>
    <VERIFY_SUSPECT timeout="1500"  />
    <BARRIER />
    <pbcast.NAKACK use_stats_for_retransmission="false"
                   exponential_backoff="150"
                   use_mcast_xmit="true" gc_lag="0"
                   retransmit_timeout="50,300,600,1200"
                   discard_delivered_msgs="true"/>
    <UNICAST timeout="300,600,1200"/>
    <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
                   max_bytes="1000000"/>
    <VIEW_SYNC avg_send_interval="60000"   />
    <pbcast.GMS print_local_addr="true" join_timeout="5000"
                shun="false"
                view_bundling="true"/>
    <FC max_credits="500000"
                    min_threshold="0.20"/>
    <FRAG2 frag_size="60000"  />
    <pbcast.STREAMING_STATE_TRANSFER />
<!--    <pbcast.STATE_TRANSFER  />-->
    <pbcast.FLUSH timeout="0"/>
</config>

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 09:55:23 2011
From: jira-events at lists.jboss.org (Sandeep T H (JIRA))
Date: Wed, 6 Jul 2011 09:55:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1343) JGroups 2.6.2 hangs
 during JChannel.connect
In-Reply-To: <219174054.37442.1309960403679.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <774052850.37450.1309960523731.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Sandeep T H updated JGRP-1343:
------------------------------

    Issue Type: Quality Risk  (was: Task)


> JGroups 2.6.2 hangs during JChannel.connect
> -------------------------------------------
>
>                 Key: JGRP-1343
>                 URL: https://issues.jboss.org/browse/JGRP-1343
>             Project: JGroups
>          Issue Type: Quality Risk
>    Affects Versions: 2.6.2
>         Environment: Linux, cluster
>            Reporter: Sandeep T H
>            Assignee: Bela Ban
>
> In a cluster having two nodes A & B, A is up and running and when B is started for the first time it sometimes hangs in JChannel.connect.
> If we bring down A then B is able to resume and connect. This issue happens randomly but frequently.
> Please let us know if we have missed something or need something.
> The jgroups configuration used is :
> <config>
>     <UDP
>          mcast_addr="${jgroups.udp.mcast_addr:224.0.0.0}"
>          mcast_port="${jgroups.udp.mcast_port:$JGroup_port}"
>          tos="8"
>          ucast_recv_buf_size="20000000"
>          ucast_send_buf_size="640000"
>          mcast_recv_buf_size="25000000"
>          mcast_send_buf_size="640000"
>          loopback="false"
>          discard_incompatible_packets="true"
>          max_bundle_size="64000"
>          max_bundle_timeout="30"
>          use_incoming_packet_handler="true"
>          ip_ttl="${jgroups.udp.ip_ttl:2}"
>          enable_bundling="true"
>          enable_diagnostics="true"
>          thread_naming_pattern="cl"
>          use_concurrent_stack="true"
>          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="1000"
>          thread_pool.rejection_policy="Run"
>          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="Run"/>
>     <PING timeout="2000"
>             num_initial_members="3"/>
>     <MERGE2 max_interval="30000"
>             min_interval="10000"/>
>     <FD_SOCK/>
>     <FD timeout="10000" max_tries="5"   shun="true"/>
>     <VERIFY_SUSPECT timeout="1500"  />
>     <BARRIER />
>     <pbcast.NAKACK use_stats_for_retransmission="false"
>                    exponential_backoff="150"
>                    use_mcast_xmit="true" gc_lag="0"
>                    retransmit_timeout="50,300,600,1200"
>                    discard_delivered_msgs="true"/>
>     <UNICAST timeout="300,600,1200"/>
>     <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
>                    max_bytes="1000000"/>
>     <VIEW_SYNC avg_send_interval="60000"   />
>     <pbcast.GMS print_local_addr="true" join_timeout="5000"
>                 shun="false"
>                 view_bundling="true"/>
>     <FC max_credits="500000"
>                     min_threshold="0.20"/>
>     <FRAG2 frag_size="60000"  />
>     <pbcast.STREAMING_STATE_TRANSFER />
> <!--    <pbcast.STATE_TRANSFER  />-->
>     <pbcast.FLUSH timeout="0"/>
> </config>

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 10:15:24 2011
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 6 Jul 2011 10:15:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1343) JGroups 2.6.2
 hangs during JChannel.connect
In-Reply-To: <219174054.37442.1309960403679.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1856376936.37476.1309961724378.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1343:
--------------------------------

2.6.2 is old, I suggest try with at least 2.6.15 (downloadable from SourceForge). 
I'm going to close this. If you can reproduce the issue, please re-open the case and add the exact steps (and the program used) to reproduce it.
You can also try a later version (branch on GitHub is Branch_JGroups_2_6), but you have to build it yourself.

> JGroups 2.6.2 hangs during JChannel.connect
> -------------------------------------------
>
>                 Key: JGRP-1343
>                 URL: https://issues.jboss.org/browse/JGRP-1343
>             Project: JGroups
>          Issue Type: Quality Risk
>    Affects Versions: 2.6.2
>         Environment: Linux, cluster
>            Reporter: Sandeep T H
>            Assignee: Bela Ban
>
> In a cluster having two nodes A & B, A is up and running and when B is started for the first time it sometimes hangs in JChannel.connect.
> If we bring down A then B is able to resume and connect. This issue happens randomly but frequently.
> Please let us know if we have missed something or need something.
> The jgroups configuration used is :
> <config>
>     <UDP
>          mcast_addr="${jgroups.udp.mcast_addr:224.0.0.0}"
>          mcast_port="${jgroups.udp.mcast_port:$JGroup_port}"
>          tos="8"
>          ucast_recv_buf_size="20000000"
>          ucast_send_buf_size="640000"
>          mcast_recv_buf_size="25000000"
>          mcast_send_buf_size="640000"
>          loopback="false"
>          discard_incompatible_packets="true"
>          max_bundle_size="64000"
>          max_bundle_timeout="30"
>          use_incoming_packet_handler="true"
>          ip_ttl="${jgroups.udp.ip_ttl:2}"
>          enable_bundling="true"
>          enable_diagnostics="true"
>          thread_naming_pattern="cl"
>          use_concurrent_stack="true"
>          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="1000"
>          thread_pool.rejection_policy="Run"
>          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="Run"/>
>     <PING timeout="2000"
>             num_initial_members="3"/>
>     <MERGE2 max_interval="30000"
>             min_interval="10000"/>
>     <FD_SOCK/>
>     <FD timeout="10000" max_tries="5"   shun="true"/>
>     <VERIFY_SUSPECT timeout="1500"  />
>     <BARRIER />
>     <pbcast.NAKACK use_stats_for_retransmission="false"
>                    exponential_backoff="150"
>                    use_mcast_xmit="true" gc_lag="0"
>                    retransmit_timeout="50,300,600,1200"
>                    discard_delivered_msgs="true"/>
>     <UNICAST timeout="300,600,1200"/>
>     <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
>                    max_bytes="1000000"/>
>     <VIEW_SYNC avg_send_interval="60000"   />
>     <pbcast.GMS print_local_addr="true" join_timeout="5000"
>                 shun="false"
>                 view_bundling="true"/>
>     <FC max_credits="500000"
>                     min_threshold="0.20"/>
>     <FRAG2 frag_size="60000"  />
>     <pbcast.STREAMING_STATE_TRANSFER />
> <!--    <pbcast.STATE_TRANSFER  />-->
>     <pbcast.FLUSH timeout="0"/>
> </config>

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 10:15:24 2011
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 6 Jul 2011 10:15:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-1343) JGroups 2.6.2 hangs
 during JChannel.connect
In-Reply-To: <219174054.37442.1309960403679.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1121083335.37480.1309961724496.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban resolved JGRP-1343.
----------------------------

    Resolution: Rejected


> JGroups 2.6.2 hangs during JChannel.connect
> -------------------------------------------
>
>                 Key: JGRP-1343
>                 URL: https://issues.jboss.org/browse/JGRP-1343
>             Project: JGroups
>          Issue Type: Quality Risk
>    Affects Versions: 2.6.2
>         Environment: Linux, cluster
>            Reporter: Sandeep T H
>            Assignee: Bela Ban
>
> In a cluster having two nodes A & B, A is up and running and when B is started for the first time it sometimes hangs in JChannel.connect.
> If we bring down A then B is able to resume and connect. This issue happens randomly but frequently.
> Please let us know if we have missed something or need something.
> The jgroups configuration used is :
> <config>
>     <UDP
>          mcast_addr="${jgroups.udp.mcast_addr:224.0.0.0}"
>          mcast_port="${jgroups.udp.mcast_port:$JGroup_port}"
>          tos="8"
>          ucast_recv_buf_size="20000000"
>          ucast_send_buf_size="640000"
>          mcast_recv_buf_size="25000000"
>          mcast_send_buf_size="640000"
>          loopback="false"
>          discard_incompatible_packets="true"
>          max_bundle_size="64000"
>          max_bundle_timeout="30"
>          use_incoming_packet_handler="true"
>          ip_ttl="${jgroups.udp.ip_ttl:2}"
>          enable_bundling="true"
>          enable_diagnostics="true"
>          thread_naming_pattern="cl"
>          use_concurrent_stack="true"
>          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="1000"
>          thread_pool.rejection_policy="Run"
>          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="Run"/>
>     <PING timeout="2000"
>             num_initial_members="3"/>
>     <MERGE2 max_interval="30000"
>             min_interval="10000"/>
>     <FD_SOCK/>
>     <FD timeout="10000" max_tries="5"   shun="true"/>
>     <VERIFY_SUSPECT timeout="1500"  />
>     <BARRIER />
>     <pbcast.NAKACK use_stats_for_retransmission="false"
>                    exponential_backoff="150"
>                    use_mcast_xmit="true" gc_lag="0"
>                    retransmit_timeout="50,300,600,1200"
>                    discard_delivered_msgs="true"/>
>     <UNICAST timeout="300,600,1200"/>
>     <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
>                    max_bytes="1000000"/>
>     <VIEW_SYNC avg_send_interval="60000"   />
>     <pbcast.GMS print_local_addr="true" join_timeout="5000"
>                 shun="false"
>                 view_bundling="true"/>
>     <FC max_credits="500000"
>                     min_threshold="0.20"/>
>     <FRAG2 frag_size="60000"  />
>     <pbcast.STREAMING_STATE_TRANSFER />
> <!--    <pbcast.STATE_TRANSFER  />-->
>     <pbcast.FLUSH timeout="0"/>
> </config>

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 10:31:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 6 Jul 2011 10:31:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-9414) Run time exception
 in Jboss 6 - org.jboss.cache.CacheException:
 java.lang.reflect.InvocationTargetException
In-Reply-To: <1676472132.37210.1309953083660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <490796702.37528.1309962683731.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on JBAS-9414:
------------------------------------

Santhosh, please create a forum thread here http://community.jboss.org/en/jbossas/config?view=discussions to discuss this issue. 

 

> Run time exception in Jboss 6 - org.jboss.cache.CacheException: java.lang.reflect.InvocationTargetException
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-9414
>                 URL: https://issues.jboss.org/browse/JBAS-9414
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>         Environment: Windows xp OS, Jboss 6 with JDK 1.6, Hibernate 3.2.0.
>            Reporter: santhosh ganapathi
>              Labels: jboss
>
> 15:29:42,059 ERROR [STDERR] org.jboss.cache.CacheException: java.lang.reflect.InvocationTargetException
> 15:29:42,059 ERROR [STDERR]     at org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:148)
> 15:29:42,059 ERROR [STDERR]     at org.jboss.cache.factories.ComponentRegistry$PrioritizedMethod.invoke(ComponentRegistry.java:970)
> 15:29:42,059 ERROR [STDERR]     at org.jboss.cache.factories.ComponentRegistry.internalStart(ComponentRegistry.java:746)
> 15:29:42,059 ERROR [STDERR]     at org.jboss.cache.factories.ComponentRegistry.start(ComponentRegistry.java:610)
> 15:29:42,059 ERROR [STDERR]     at org.jboss.cache.invocation.CacheInvocationDelegate.start(CacheInvocationDelegate.java:355)
> 15:29:42,059 ERROR [STDERR]     at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:121)
> 15:29:42,059 ERROR [STDERR]     at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:72)
> 15:29:42,059 ERROR [STDERR]     at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:67)
> 15:29:42,059 ERROR [STDERR]     at com.csscorp.presentation.spinneret.server.HRMSShadesGeneratorImpl.extractSpinneretPanel(HRMSShadesGeneratorImpl.java:114)
> 15:29:42,059 ERROR [STDERR]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 15:29:42,059 ERROR [STDERR]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 15:29:42,059 ERROR [STDERR]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 15:29:42,059 ERROR [STDERR]     at java.lang.reflect.Method.invoke(Method.java:597)
> 15:29:42,059 ERROR [STDERR]     at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:569)
> 15:29:42,059 ERROR [STDERR]     at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:208)
> 15:29:42,074 ERROR [STDERR]     at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:248)
> 15:29:42,074 ERROR [STDERR]     at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
> 15:29:42,074 ERROR [STDERR]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
> 15:29:42,074 ERROR [STDERR]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> 15:29:42,074 ERROR [STDERR]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324)
> 15:29:42,074 ERROR [STDERR]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242)
> 15:29:42,074 ERROR [STDERR]     at com.csscorp.business.filter.HRMSLoginFilter.doFilter(HRMSLoginFilter.java:55)
> 15:29:42,090 ERROR [STDERR]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274)
> 15:29:42,090 ERROR [STDERR]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242)
> 15:29:42,090 ERROR [STDERR]     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> 15:29:42,090 ERROR [STDERR]     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 15:29:42,090 ERROR [STDERR]     at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:181)
> 15:29:42,090 ERROR [STDERR]     at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285)
> 15:29:42,090 ERROR [STDERR]     at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261)
> 15:29:42,090 ERROR [STDERR]     at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:88)
> 15:29:42,106 ERROR [STDERR]     at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:100)
> 15:29:42,106 ERROR [STDERR]     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 15:29:42,106 ERROR [STDERR]     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 15:29:42,106 ERROR [STDERR]     at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 15:29:42,106 ERROR [STDERR]     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 15:29:42,106 ERROR [STDERR]     at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53)
> 15:29:42,106 ERROR [STDERR]     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
> 15:29:42,121 ERROR [STDERR]     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> 15:29:42,121 ERROR [STDERR]     at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:654)
> 15:29:42,121 ERROR [STDERR]     at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951)
> 15:29:42,121 ERROR [STDERR]     at java.lang.Thread.run(Thread.java:619)
> 15:29:42,121 ERROR [STDERR] Caused by: java.lang.reflect.InvocationTargetException
> 15:29:42,121 ERROR [STDERR]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 15:29:42,137 ERROR [STDERR]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 15:29:42,137 ERROR [STDERR]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 15:29:42,137 ERROR [STDERR]     at java.lang.reflect.Method.invoke(Method.java:597)
> 15:29:42,137 ERROR [STDERR]     at org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:144)
> 15:29:42,137 ERROR [STDERR]     ... 40 more
> 15:29:42,137 ERROR [STDERR] Caused by: java.lang.LinkageError: loader constraint violation: when resolving method "java.lang.management.ManagementFactory.getPlatformMBeanServer()Ljavax/management/MBeanServer;" the class loader (instance of org/jboss/classloader/spi/base/BaseClassLoader) of the current class, org/jboss/cache/jmx/JmxRegistrationManager, and the class loader (instance of <bootloader>) for resolved class, java/lang/management/ManagementFactory, have different Class objects for the type javax/management/MBeanServer used in the signature
> 15:29:42,137 ERROR [STDERR]     at org.jboss.cache.jmx.JmxRegistrationManager.<init>(JmxRegistrationManager.java:128)
> 15:29:42,153 ERROR [STDERR]     at org.jboss.cache.jmx.JmxRegistrationManager.<init>(JmxRegistrationManager.java:133)
> 15:29:42,153 ERROR [STDERR]     at org.jboss.cache.jmx.PlatformMBeanServerRegistration.registerToPlatformMBeanServer(PlatformMBeanServerRegistration.java:69)
> 15:29:42,153 ERROR [STDERR]     ... 45 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 10:31:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Wed, 6 Jul 2011 10:31:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1196) NPE during session
 ownership acquisition on failover.
In-Reply-To: <1710949728.36674.1309922363762.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <179530443.37531.1309962683856.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro resolved AS7-1196.
-------------------------------

    Resolution: Done


> NPE during session ownership acquisition on failover.
> -----------------------------------------------------
>
>                 Key: AS7-1196
>                 URL: https://issues.jboss.org/browse/AS7-1196
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.CR1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 7.0.0.Final
>
>
> Since migration to complex key for sessions, session ownership logic needs to lock on simple key, since they will be deserialized eagerly, while still allowing CoreGroupCommunicationService to deserialize its own rpc objects.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 10:31:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 6 Jul 2011 10:31:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-9414) Run time exception in
 Jboss 6 - org.jboss.cache.CacheException:
 java.lang.reflect.InvocationTargetException
In-Reply-To: <1676472132.37210.1309953083660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1676720421.37533.1309962683937.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai closed JBAS-9414.
------------------------------

    Resolution: Rejected


> Run time exception in Jboss 6 - org.jboss.cache.CacheException: java.lang.reflect.InvocationTargetException
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-9414
>                 URL: https://issues.jboss.org/browse/JBAS-9414
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>         Environment: Windows xp OS, Jboss 6 with JDK 1.6, Hibernate 3.2.0.
>            Reporter: santhosh ganapathi
>              Labels: jboss
>
> 15:29:42,059 ERROR [STDERR] org.jboss.cache.CacheException: java.lang.reflect.InvocationTargetException
> 15:29:42,059 ERROR [STDERR]     at org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:148)
> 15:29:42,059 ERROR [STDERR]     at org.jboss.cache.factories.ComponentRegistry$PrioritizedMethod.invoke(ComponentRegistry.java:970)
> 15:29:42,059 ERROR [STDERR]     at org.jboss.cache.factories.ComponentRegistry.internalStart(ComponentRegistry.java:746)
> 15:29:42,059 ERROR [STDERR]     at org.jboss.cache.factories.ComponentRegistry.start(ComponentRegistry.java:610)
> 15:29:42,059 ERROR [STDERR]     at org.jboss.cache.invocation.CacheInvocationDelegate.start(CacheInvocationDelegate.java:355)
> 15:29:42,059 ERROR [STDERR]     at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:121)
> 15:29:42,059 ERROR [STDERR]     at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:72)
> 15:29:42,059 ERROR [STDERR]     at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:67)
> 15:29:42,059 ERROR [STDERR]     at com.csscorp.presentation.spinneret.server.HRMSShadesGeneratorImpl.extractSpinneretPanel(HRMSShadesGeneratorImpl.java:114)
> 15:29:42,059 ERROR [STDERR]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 15:29:42,059 ERROR [STDERR]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 15:29:42,059 ERROR [STDERR]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 15:29:42,059 ERROR [STDERR]     at java.lang.reflect.Method.invoke(Method.java:597)
> 15:29:42,059 ERROR [STDERR]     at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:569)
> 15:29:42,059 ERROR [STDERR]     at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:208)
> 15:29:42,074 ERROR [STDERR]     at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:248)
> 15:29:42,074 ERROR [STDERR]     at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
> 15:29:42,074 ERROR [STDERR]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
> 15:29:42,074 ERROR [STDERR]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> 15:29:42,074 ERROR [STDERR]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324)
> 15:29:42,074 ERROR [STDERR]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242)
> 15:29:42,074 ERROR [STDERR]     at com.csscorp.business.filter.HRMSLoginFilter.doFilter(HRMSLoginFilter.java:55)
> 15:29:42,090 ERROR [STDERR]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274)
> 15:29:42,090 ERROR [STDERR]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242)
> 15:29:42,090 ERROR [STDERR]     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> 15:29:42,090 ERROR [STDERR]     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 15:29:42,090 ERROR [STDERR]     at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:181)
> 15:29:42,090 ERROR [STDERR]     at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285)
> 15:29:42,090 ERROR [STDERR]     at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261)
> 15:29:42,090 ERROR [STDERR]     at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:88)
> 15:29:42,106 ERROR [STDERR]     at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:100)
> 15:29:42,106 ERROR [STDERR]     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 15:29:42,106 ERROR [STDERR]     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 15:29:42,106 ERROR [STDERR]     at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 15:29:42,106 ERROR [STDERR]     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 15:29:42,106 ERROR [STDERR]     at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53)
> 15:29:42,106 ERROR [STDERR]     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
> 15:29:42,121 ERROR [STDERR]     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> 15:29:42,121 ERROR [STDERR]     at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:654)
> 15:29:42,121 ERROR [STDERR]     at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951)
> 15:29:42,121 ERROR [STDERR]     at java.lang.Thread.run(Thread.java:619)
> 15:29:42,121 ERROR [STDERR] Caused by: java.lang.reflect.InvocationTargetException
> 15:29:42,121 ERROR [STDERR]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 15:29:42,137 ERROR [STDERR]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 15:29:42,137 ERROR [STDERR]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 15:29:42,137 ERROR [STDERR]     at java.lang.reflect.Method.invoke(Method.java:597)
> 15:29:42,137 ERROR [STDERR]     at org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:144)
> 15:29:42,137 ERROR [STDERR]     ... 40 more
> 15:29:42,137 ERROR [STDERR] Caused by: java.lang.LinkageError: loader constraint violation: when resolving method "java.lang.management.ManagementFactory.getPlatformMBeanServer()Ljavax/management/MBeanServer;" the class loader (instance of org/jboss/classloader/spi/base/BaseClassLoader) of the current class, org/jboss/cache/jmx/JmxRegistrationManager, and the class loader (instance of <bootloader>) for resolved class, java/lang/management/ManagementFactory, have different Class objects for the type javax/management/MBeanServer used in the signature
> 15:29:42,137 ERROR [STDERR]     at org.jboss.cache.jmx.JmxRegistrationManager.<init>(JmxRegistrationManager.java:128)
> 15:29:42,153 ERROR [STDERR]     at org.jboss.cache.jmx.JmxRegistrationManager.<init>(JmxRegistrationManager.java:133)
> 15:29:42,153 ERROR [STDERR]     at org.jboss.cache.jmx.PlatformMBeanServerRegistration.registerToPlatformMBeanServer(PlatformMBeanServerRegistration.java:69)
> 15:29:42,153 ERROR [STDERR]     ... 45 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 10:41:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 6 Jul 2011 10:41:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1210) Messaging subsystem
 binds JMS destinations to java:
Message-ID: <1452571861.37545.1309963283664.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Messaging subsystem binds JMS destinations to java:
---------------------------------------------------

                 Key: AS7-1210
                 URL: https://issues.jboss.org/browse/AS7-1210
             Project: Application Server 7
          Issue Type: Bug
          Components: JMS
    Affects Versions: 7.0.0.CR1
            Reporter: jaikiran pai


As per the discussion in this mail thread http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/002890.html:
{quote}
1) Unqualified relative names like "DefaultDS" or "jdbc/DefaultDS" 
should be qualified relative to "java:comp/env", "java:module/env", or 
"java:jboss/env", depending on the context.
{quote}

So in case of JMS destinations configured in the standalone.xml/domain.xml, JNDI entries like these:
{code:xml}
           <jms-destinations>
              <jms-queue name="testQueue">
                 <entry name="queue/test"/>
              </jms-queue>
              <jms-topic name="testTopic">
                 <entry name="topic/test"/>
              </jms-topic>
           </jms-destinations>
{code}

should bind under java:jboss/ namespace. 

Instead, currently the org.jboss.as.messaging.jms.AS7BindingRegistry binds it to java: namespace.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 10:45:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 6 Jul 2011 10:45:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1210) Messaging subsystem
 binds JMS destinations to java:
In-Reply-To: <1452571861.37545.1309963283664.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <26946573.37553.1309963523959.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai updated AS7-1210:
------------------------------

    Forum Reference: http://community.jboss.org/message/613662#613662


> Messaging subsystem binds JMS destinations to java:
> ---------------------------------------------------
>
>                 Key: AS7-1210
>                 URL: https://issues.jboss.org/browse/AS7-1210
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 7.0.0.CR1
>            Reporter: jaikiran pai
>
> As per the discussion in this mail thread http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/002890.html:
> {quote}
> 1) Unqualified relative names like "DefaultDS" or "jdbc/DefaultDS" 
> should be qualified relative to "java:comp/env", "java:module/env", or 
> "java:jboss/env", depending on the context.
> {quote}
> So in case of JMS destinations configured in the standalone.xml/domain.xml, JNDI entries like these:
> {code:xml}
>            <jms-destinations>
>               <jms-queue name="testQueue">
>                  <entry name="queue/test"/>
>               </jms-queue>
>               <jms-topic name="testTopic">
>                  <entry name="topic/test"/>
>               </jms-topic>
>            </jms-destinations>
> {code}
> should bind under java:jboss/ namespace. 
> Instead, currently the org.jboss.as.messaging.jms.AS7BindingRegistry binds it to java: namespace.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 10:47:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 6 Jul 2011 10:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1211) Implement
 jboss-ejb3.xml processing
Message-ID: <443977748.37556.1309963643629.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Implement jboss-ejb3.xml processing
-----------------------------------

                 Key: AS7-1211
                 URL: https://issues.jboss.org/browse/AS7-1211
             Project: Application Server 7
          Issue Type: Task
          Components: EJB
            Reporter: Carlo de Wolf
            Assignee: Carlo de Wolf
            Priority: Critical
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 10:53:23 2011
From: jira-events at lists.jboss.org (Artur Karpinski (JIRA))
Date: Wed, 6 Jul 2011 10:53:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-1297) Deadlock between
 MicroRemoteClientInvoker.establishLease and Client.notifyListeners
Message-ID: <1642877588.37570.1309964003690.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Deadlock between MicroRemoteClientInvoker.establishLease and Client.notifyListeners
-----------------------------------------------------------------------------------

                 Key: JBREM-1297
                 URL: https://issues.jboss.org/browse/JBREM-1297
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.5.4.SP2
            Reporter: Artur Karpinski
            Priority: Critical


Deadlock is probably caused by changes introduced in this fix: JBREM-1242.

Thread A:
1. MicroRemoteClientInvoker.terminateLease, locks clientLeaseLock
2. Client.notifyListeners, locks connectionValidatorLock

Thread B:
1. Client.setupClientLease, locks connectionValidatorLock
2. MicroRemoteClientInvoker.establishLease, locks connectionValidatorLock

Please check stacktraces when this deadlock occurred:

{code}
"Timer-16" - Thread t at 486453
   java.lang.Thread.State: BLOCKED
	at org.jboss.remoting.Client.notifyListeners(Client.java:1873)
	- waiting to lock <747c39d3> (a java.lang.Object) owned by "WorkManager(2)-241" t at 6121
	at org.jboss.remoting.LeasePinger.stopPing(LeasePinger.java:134)
	at org.jboss.remoting.MicroRemoteClientInvoker.terminateLease(MicroRemoteClientInvoker.java:434)
	- locked <751714e> (a java.lang.Object)
	at org.jboss.remoting.ConnectionValidator$WaitOnConnectionCheckTimerTask.run(ConnectionValidator.java:1081)
	at java.util.TimerThread.mainLoop(Timer.java:512)
	at java.util.TimerThread.run(Timer.java:462)
{code}

and

{code}
"WorkManager(2)-241" - Thread t at 6121
   java.lang.Thread.State: BLOCKED
	at org.jboss.remoting.MicroRemoteClientInvoker.establishLease(MicroRemoteClientInvoker.java:507)
	- waiting to lock <751714e> (a java.lang.Object) owned by "Timer-16" t at 486453
	at org.jboss.remoting.Client.setupClientLease(Client.java:2056)
	- locked <747c39d3> (a java.lang.Object)
	at org.jboss.remoting.Client.connect(Client.java:1918)
	at org.jboss.remoting.Client.connect(Client.java:737)
{code}

One way to fix this would be to add lock on connectionValidatorLock in MicroRemoteClientInvoker.terminateLease. I'm trying to analyse code to check if this fix will not introduce another deadlock problem.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 11:00:24 2011
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Wed, 6 Jul 2011 11:00:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-407) Ensure that connectors
 that handle end user request start late in the server start process
In-Reply-To: <410655551.4324.1284654748613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1786162708.37581.1309964424073.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Emanuel Muckenhuber updated AS7-407:
------------------------------------

    Assignee:     (was: Emanuel Muckenhuber)


> Ensure that connectors that handle end user request start late in the server start process
> ------------------------------------------------------------------------------------------
>
>                 Key: AS7-407
>                 URL: https://issues.jboss.org/browse/AS7-407
>             Project: Application Server 7
>          Issue Type: Task
>            Reporter: Brian Stansberry
>             Fix For: 7.1.0.Alpha1
>
>
> Ensure all connectors that handle user requests have appropriate behavior with respect to not starting until the overall server start is in a state where the connector can handle the expected requests.
> Part of this is understanding how the clients work; i.e. for some connectors clients may never send a request that the server can't correctly handle. For others, e.g. web connectors fronted by mod_jk or most hardware load balancers, once the connector is started, it may start receiving requests for apps that are not deployed.
> This is somewhat related to graceful shutdown, where the connector should stop handling requests at the appropriate point in a shutdown process.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 11:02:23 2011
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Wed, 6 Jul 2011 11:02:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-484) graceful shutdown
In-Reply-To: <1671156476.19083.1281436309093.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1086378077.37587.1309964543985.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Emanuel Muckenhuber updated AS7-484:
------------------------------------

    Assignee:     (was: Emanuel Muckenhuber)


> graceful shutdown
> -----------------
>
>                 Key: AS7-484
>                 URL: https://issues.jboss.org/browse/AS7-484
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Emanuel Muckenhuber
>             Fix For: 7.1.0.Beta1
>
>
> We need to define a clear contract between these networking services and the services that use them in order to be able to perform a graceful shutdown of remote connectors.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 11:32:23 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Wed, 6 Jul 2011 11:32:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1212)
 :read-operation-description(name=add) shows pool-name as optional,
 but deploy without pool-name fail
Message-ID: <2010325607.37641.1309966343681.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

:read-operation-description(name=add) shows pool-name as optional, but deploy without pool-name fail
----------------------------------------------------------------------------------------------------

                 Key: AS7-1212
                 URL: https://issues.jboss.org/browse/AS7-1212
             Project: Application Server 7
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 7.0.0.CR1
            Reporter: Heiko Rupp
            Assignee: Brian Stansberry


[domain at localhost:9999 subsystem=datasources] ./data-source=java\:jboss\/datasources\/ExampleDS:read-operation-description(name=add)
{
    "outcome" => "success",
    "result" => {
        "operation-name" => "add",
        "description" => "Adds a new data-source",
        "request-properties" => {
....
       "pool-name" => {
                "description" => "Specifies the pool name for the datasource used for management",
                "type" => STRING,
                "required" => false
            },

So the pool-name is optional, but when I deploy a data source without pool name, deployment fails: 

[Server:server-one] 17:26:49,124 ERROR [stderr] (pool-1-thread-42) org.jboss.jca.common.api.validator.ValidateException: IJ010068: Missing required attribute pool-name in org.jboss.jca.common.metadata.ds.DataSourceImpl

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 11:34:24 2011
From: jira-events at lists.jboss.org (Michael Anstis (JIRA))
Date: Wed, 6 Jul 2011 11:34:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-3118) Parser: import
 of class with "enum" in the FQN fails to parse
In-Reply-To: <601618379.34171.1309808723828.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1177398180.37676.1309966464695.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Michael Anstis reassigned JBRULES-3118:
---------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)


I hope you had a nice vacation.

> Parser: import of class with "enum" in the FQN fails to parse
> -------------------------------------------------------------
>
>                 Key: JBRULES-3118
>                 URL: https://issues.jboss.org/browse/JBRULES-3118
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.2.0.Final
>            Reporter: Michael Anstis
>            Assignee: Edson Tirelli
>
> The following DRL fails to compile, with error "Syntax error on token "enum", Identifier expected."
> package com.sample
>  
> import com.sample.DroolsTest.Message;
> //The "enum" sub-package causes the problem, not "Enum" class
> import org.apache.commons.lang.enum.Enum
> rule "Hello World"
>     when
>         m : Message( status == Message.HELLO, myMessage : message )
>     then
>         System.out.println( myMessage );
>         m.setMessage( "Goodbye cruel world" );
>         m.setStatus( Message.GOODBYE );
>         update( m );
> end
> rule "GoodBye"
>     when
>         Message( status == Message.GOODBYE, myMessage : message )
>     then
>         System.out.println( myMessage );
> end

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 11:52:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Jul 2011 11:52:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1212)
 :read-operation-description(name=add) shows pool-name as optional,
 but deploy without pool-name fail
In-Reply-To: <2010325607.37641.1309966343681.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <633485827.37705.1309967543856.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-1212:
----------------------------------

       Assignee: Stefano Maestri  (was: Brian Stansberry)
    Component/s: JCA


> :read-operation-description(name=add) shows pool-name as optional, but deploy without pool-name fail
> ----------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1212
>                 URL: https://issues.jboss.org/browse/AS7-1212
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management, JCA
>    Affects Versions: 7.0.0.CR1
>            Reporter: Heiko Rupp
>            Assignee: Stefano Maestri
>
> [domain at localhost:9999 subsystem=datasources] ./data-source=java\:jboss\/datasources\/ExampleDS:read-operation-description(name=add)
> {
>     "outcome" => "success",
>     "result" => {
>         "operation-name" => "add",
>         "description" => "Adds a new data-source",
>         "request-properties" => {
> ....
>        "pool-name" => {
>                 "description" => "Specifies the pool name for the datasource used for management",
>                 "type" => STRING,
>                 "required" => false
>             },
> So the pool-name is optional, but when I deploy a data source without pool name, deployment fails: 
> [Server:server-one] 17:26:49,124 ERROR [stderr] (pool-1-thread-42) org.jboss.jca.common.api.validator.ValidateException: IJ010068: Missing required attribute pool-name in org.jboss.jca.common.metadata.ds.DataSourceImpl

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 11:52:23 2011
From: jira-events at lists.jboss.org (Kevin Conner (JIRA))
Date: Wed, 6 Jul 2011 11:52:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1884)
 ClientTransaction alters wire format
Message-ID: <986237120.37710.1309967543969.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

ClientTransaction alters wire format
------------------------------------

                 Key: JBMESSAGING-1884
                 URL: https://issues.jboss.org/browse/JBMESSAGING-1884
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core
    Affects Versions: 1.4.8.SP1
            Reporter: Kevin Conner
            Assignee: Justin Bertram


JBMESSAGING-1786 changed the format of ClientTransaction to include a recovery flag, unfortunately this breaks the wire protocol with older clients.

The versions containing this problem are
  - 1.4.0 SP3 CP11, CP12, CP13
  - 1.4.6 GA SP1
  - 1.4.7 GA
  - 1.4.8 GA
  - 1.4.8 SP1

Attached to this issue is a diff, made against the current Branch_1_4, which addresses the issue.

Older clients should still be able to talk to the newer server but will not be able to take advantage of the fix for JBMESSAGING-1786.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 11:54:23 2011
From: jira-events at lists.jboss.org (Kevin Conner (JIRA))
Date: Wed, 6 Jul 2011 11:54:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1884)
 ClientTransaction alters wire format
In-Reply-To: <986237120.37710.1309967543969.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1588832035.37714.1309967663704.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Kevin Conner updated JBMESSAGING-1884:
--------------------------------------

    Attachment: transaction.diffs


> ClientTransaction alters wire format
> ------------------------------------
>
>                 Key: JBMESSAGING-1884
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1884
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.8.SP1
>            Reporter: Kevin Conner
>            Assignee: Justin Bertram
>         Attachments: transaction.diffs
>
>
> JBMESSAGING-1786 changed the format of ClientTransaction to include a recovery flag, unfortunately this breaks the wire protocol with older clients.
> The versions containing this problem are
>   - 1.4.0 SP3 CP11, CP12, CP13
>   - 1.4.6 GA SP1
>   - 1.4.7 GA
>   - 1.4.8 GA
>   - 1.4.8 SP1
> Attached to this issue is a diff, made against the current Branch_1_4, which addresses the issue.
> Older clients should still be able to talk to the newer server but will not be able to take advantage of the fix for JBMESSAGING-1786.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 11:54:23 2011
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 6 Jul 2011 11:54:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3118) Parser: import
 of class with "enum" in the FQN fails to parse
In-Reply-To: <601618379.34171.1309808723828.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1316825545.37723.1309967663929.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Edson Tirelli commented on JBRULES-3118:
----------------------------------------

"enum" is a reserved keyword in Java 1.5+, so you can't define a package name that contains it.

http://commons.apache.org/lang/api-2.3/org/apache/commons/lang/enum/Enum.html

"Deprecated. Replaced by org.apache.commons.lang.enums.Enum and will be removed in version 3.0. All classes in this package are deprecated and repackaged to org.apache.commons.lang.enums since enum is a Java 1.5 keyword."

I don't think there is anything we can (should) do here, as this is a Java compilation error, not a drools compilation error. 

> Parser: import of class with "enum" in the FQN fails to parse
> -------------------------------------------------------------
>
>                 Key: JBRULES-3118
>                 URL: https://issues.jboss.org/browse/JBRULES-3118
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.2.0.Final
>            Reporter: Michael Anstis
>            Assignee: Edson Tirelli
>
> The following DRL fails to compile, with error "Syntax error on token "enum", Identifier expected."
> package com.sample
>  
> import com.sample.DroolsTest.Message;
> //The "enum" sub-package causes the problem, not "Enum" class
> import org.apache.commons.lang.enum.Enum
> rule "Hello World"
>     when
>         m : Message( status == Message.HELLO, myMessage : message )
>     then
>         System.out.println( myMessage );
>         m.setMessage( "Goodbye cruel world" );
>         m.setStatus( Message.GOODBYE );
>         update( m );
> end
> rule "GoodBye"
>     when
>         Message( status == Message.GOODBYE, myMessage : message )
>     then
>         System.out.println( myMessage );
> end

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 11:56:23 2011
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 6 Jul 2011 11:56:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-3118) Parser: import
 of class with "enum" in the FQN fails to parse
In-Reply-To: <601618379.34171.1309808723828.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2041565841.37727.1309967783706.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Edson Tirelli resolved JBRULES-3118.
------------------------------------

    Fix Version/s: 5.2.1.Final
                   5.3.0.Beta1
       Resolution: Rejected


Please reopen if I am missing anything.

> Parser: import of class with "enum" in the FQN fails to parse
> -------------------------------------------------------------
>
>                 Key: JBRULES-3118
>                 URL: https://issues.jboss.org/browse/JBRULES-3118
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.2.0.Final
>            Reporter: Michael Anstis
>            Assignee: Edson Tirelli
>             Fix For: 5.2.1.Final, 5.3.0.Beta1
>
>
> The following DRL fails to compile, with error "Syntax error on token "enum", Identifier expected."
> package com.sample
>  
> import com.sample.DroolsTest.Message;
> //The "enum" sub-package causes the problem, not "Enum" class
> import org.apache.commons.lang.enum.Enum
> rule "Hello World"
>     when
>         m : Message( status == Message.HELLO, myMessage : message )
>     then
>         System.out.println( myMessage );
>         m.setMessage( "Goodbye cruel world" );
>         m.setStatus( Message.GOODBYE );
>         update( m );
> end
> rule "GoodBye"
>     when
>         Message( status == Message.GOODBYE, myMessage : message )
>     then
>         System.out.println( myMessage );
> end

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 11:56:23 2011
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 6 Jul 2011 11:56:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-3118) Parser: import of
 class with "enum" in the FQN fails to parse
In-Reply-To: <601618379.34171.1309808723828.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1963221752.37731.1309967783793.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Edson Tirelli closed JBRULES-3118.
----------------------------------



> Parser: import of class with "enum" in the FQN fails to parse
> -------------------------------------------------------------
>
>                 Key: JBRULES-3118
>                 URL: https://issues.jboss.org/browse/JBRULES-3118
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.2.0.Final
>            Reporter: Michael Anstis
>            Assignee: Edson Tirelli
>             Fix For: 5.2.1.Final, 5.3.0.Beta1
>
>
> The following DRL fails to compile, with error "Syntax error on token "enum", Identifier expected."
> package com.sample
>  
> import com.sample.DroolsTest.Message;
> //The "enum" sub-package causes the problem, not "Enum" class
> import org.apache.commons.lang.enum.Enum
> rule "Hello World"
>     when
>         m : Message( status == Message.HELLO, myMessage : message )
>     then
>         System.out.println( myMessage );
>         m.setMessage( "Goodbye cruel world" );
>         m.setStatus( Message.GOODBYE );
>         update( m );
> end
> rule "GoodBye"
>     when
>         Message( status == Message.GOODBYE, myMessage : message )
>     then
>         System.out.println( myMessage );
> end

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 12:11:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 6 Jul 2011 12:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-612) Track component
	updates
Message-ID: <2087031214.37776.1309968683690.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Track component updates
-----------------------

                 Key: JBJCA-612
                 URL: https://issues.jboss.org/browse/JBJCA-612
             Project: IronJacamar
          Issue Type: Task
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Final




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 12:11:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 6 Jul 2011 12:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-613) JBoss Logging
	3.0.0.GA
Message-ID: <1403401756.37779.1309968683789.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

JBoss Logging 3.0.0.GA
----------------------

                 Key: JBJCA-613
                 URL: https://issues.jboss.org/browse/JBJCA-613
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Final




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 12:11:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 6 Jul 2011 12:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-614) PicketBox 4.0.0.CR1
Message-ID: <830823337.37781.1309968683840.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

PicketBox 4.0.0.CR1
-------------------

                 Key: JBJCA-614
                 URL: https://issues.jboss.org/browse/JBJCA-614
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Final




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 12:11:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 6 Jul 2011 12:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-615) SLF4J LogManager
	1.0.0.GA
Message-ID: <1880663443.37783.1309968683900.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

SLF4J LogManager 1.0.0.GA
-------------------------

                 Key: JBJCA-615
                 URL: https://issues.jboss.org/browse/JBJCA-615
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Final




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 12:13:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 6 Jul 2011 12:13:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-616) JBoss Stdio 1.0.0.GA
Message-ID: <294598216.37788.1309968803651.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

JBoss Stdio 1.0.0.GA
--------------------

                 Key: JBJCA-616
                 URL: https://issues.jboss.org/browse/JBJCA-616
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Final




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 12:13:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 6 Jul 2011 12:13:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-617) JBoss Threads
	2.0.0.GA
Message-ID: <662627998.37791.1309968803753.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

JBoss Threads 2.0.0.GA
----------------------

                 Key: JBJCA-617
                 URL: https://issues.jboss.org/browse/JBJCA-617
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Final




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 12:15:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 6 Jul 2011 12:15:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-618) SLF4J 1.6.1
Message-ID: <1891272773.37794.1309968923834.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

SLF4J 1.6.1
-----------

                 Key: JBJCA-618
                 URL: https://issues.jboss.org/browse/JBJCA-618
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.0.Final




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 12:17:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 6 Jul 2011 12:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-619) JBoss Logging
	3.0.0.GA
Message-ID: <1444143148.37806.1309969043630.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

JBoss Logging 3.0.0.GA
----------------------

                 Key: JBJCA-619
                 URL: https://issues.jboss.org/browse/JBJCA-619
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.1.0.Alpha1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 12:19:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 6 Jul 2011 12:19:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-620) PicketBox 4.0.0.CR1
Message-ID: <1053123638.37810.1309969163706.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

PicketBox 4.0.0.CR1
-------------------

                 Key: JBJCA-620
                 URL: https://issues.jboss.org/browse/JBJCA-620
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.1.0.Alpha1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 12:19:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 6 Jul 2011 12:19:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-621) SLF4J LogManager
	1.0.0.GA
Message-ID: <1270276689.37813.1309969163777.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

SLF4J LogManager 1.0.0.GA
-------------------------

                 Key: JBJCA-621
                 URL: https://issues.jboss.org/browse/JBJCA-621
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.1.0.Alpha1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 12:19:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 6 Jul 2011 12:19:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-622) JBoss Stdio 1.0.0.GA
Message-ID: <652232981.37815.1309969163893.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

JBoss Stdio 1.0.0.GA
--------------------

                 Key: JBJCA-622
                 URL: https://issues.jboss.org/browse/JBJCA-622
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.1.0.Alpha1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 12:19:24 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 6 Jul 2011 12:19:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-623) JBoss Threads
	2.0.0.GA
Message-ID: <2112295062.37817.1309969164026.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

JBoss Threads 2.0.0.GA
----------------------

                 Key: JBJCA-623
                 URL: https://issues.jboss.org/browse/JBJCA-623
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.1.0.Alpha1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 12:21:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 6 Jul 2011 12:21:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-624) SLF4J 1.6.1
Message-ID: <404889235.37821.1309969283614.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

SLF4J 1.6.1
-----------

                 Key: JBJCA-624
                 URL: https://issues.jboss.org/browse/JBJCA-624
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.1.0.Alpha1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 13:40:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Jul 2011 13:40:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-462) Patching system
In-Reply-To: <1288913815.1995.1279060258967.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <188437297.37886.1309974023795.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on AS7-462:
--------------------------------------

For Alpha1, we need to have the schema that describes patches and how to install them done, along with related object model and parsing stuff. The foundational infrastructure for storing the patch modules separately from the original modules and updating the module path to use them needs to be done. And a clear path (i.e. design and fairly specific tasks) for the remaining work needs to be complete.

Finishing the implementation can then be a 7.1.0.Beta1 task.

> Patching system
> ---------------
>
>                 Key: AS7-462
>                 URL: https://issues.jboss.org/browse/AS7-462
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 7.1.0.Alpha1
>
>
> "Server" side of the patching system. Server not in the sense of the domain model Server, but rather client-server where the client is whatever tool (JON) determines there are patches available and asks the server to apply them.
> This does not need to implemented until M2 but thinking about it during the design of the InstalledImage is good.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 13:44:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Jul 2011 13:44:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-515) Tighten up the
 ServerEnvironment and HostControllerEnvironment contracts
In-Reply-To: <645464062.12433.1301509417914.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1350975366.37890.1309974263709.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-515:
---------------------------------

    Fix Version/s: 7.1.0.Beta1
                       (was: 7.1.0.Alpha1)


> Tighten up the ServerEnvironment and HostControllerEnvironment contracts
> ------------------------------------------------------------------------
>
>                 Key: AS7-515
>                 URL: https://issues.jboss.org/browse/AS7-515
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 7.1.0.Beta1
>
>
> Right now the contract/usage of these classes is a bit of a mishmash. The idea was to store state that's read from Main(). But if there's anything in these that can be overridden from standalone.xml, either we should restrict access to that data or make sure that it has the correct value if a change is made via the management API. For example, the server name can come from standalone.xml if the 'name' attribute is set and for sure will come from the HostController in domain mode.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 13:46:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Jul 2011 13:46:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-489) Validate any
 domain/host/standalone config files we ship
In-Reply-To: <312572347.13773.1286207860354.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1982946791.37896.1309974383783.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry resolved AS7-489.
----------------------------------

    Fix Version/s: 7.0.0.CR1
                       (was: 7.1.0.Alpha1)
       Resolution: Done


> Validate any domain/host/standalone config files we ship
> --------------------------------------------------------
>
>                 Key: AS7-489
>                 URL: https://issues.jboss.org/browse/AS7-489
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: John Bailey
>             Fix For: 7.0.0.CR1
>
>
> As part of the testsuite smoke tests, validate any config files we ship.
> There is already a smoke test that does something like this, but it is validating example files. It should validate the real files.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 13:48:25 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Jul 2011 13:48:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-314) Expose the domain
 management API over JMX
In-Reply-To: <1954554933.40463.1300735011657.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <606790701.37928.1309974505450.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-314:
---------------------------------

    Fix Version/s: 7.1.0.Alpha1
                       (was: 7.1.0.Beta1)


> Expose the domain management API over JMX
> -----------------------------------------
>
>                 Key: AS7-314
>                 URL: https://issues.jboss.org/browse/AS7-314
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Priority: Critical
>             Fix For: 7.1.0.Alpha1
>
>
> Create a JMX domain for the AS 7 management layer; expose management resources as mbeans.
> Two options:
> 1) An mbean per resource.
> 2) Create an adapter layer.
> Requirement: do not add significant boot time overhead. Populating the mbean server in the background is permissible.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 13:48:25 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Jul 2011 13:48:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-402) Handle reconnection of
 hosts to the domain
In-Reply-To: <914406730.40841.1300743285866.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1734073040.37930.1309974505523.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-402:
---------------------------------

    Fix Version/s: 7.1.0.Alpha1
                       (was: 7.1.0.Beta1)


> Handle reconnection of hosts to the domain
> ------------------------------------------
>
>                 Key: AS7-402
>                 URL: https://issues.jboss.org/browse/AS7-402
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Priority: Critical
>             Fix For: 7.1.0.Alpha1
>
>
> Establish processes for host controllers to reconnect to the master domain controller if communication is disrupted and thereafter synchronize themselves (and their servers) with the domain.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 13:50:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Jul 2011 13:50:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-444) Audit logging
In-Reply-To: <1429526006.40541.1300736565637.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1472698822.37935.1309974623723.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-444:
---------------------------------

    Fix Version/s: 7.1.0.Alpha1
                       (was: 7.1.0.Beta1)


> Audit logging
> -------------
>
>                 Key: AS7-444
>                 URL: https://issues.jboss.org/browse/AS7-444
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: John Bailey
>            Priority: Critical
>             Fix For: 7.1.0.Alpha1
>
>
> All modifications through the administrative infrastructure will be audited. The administrative audit log will be tamper proof.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 13:50:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Jul 2011 13:50:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-759) Subsystem "messaging":
 security-settings and addressing settings should be subresoures
In-Reply-To: <1135842452.788.1305210691668.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1629337127.37940.1309974624140.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-759:
---------------------------------

    Fix Version/s: 7.1.0.Alpha1
                       (was: 7.1.0.Beta1)


> Subsystem "messaging": security-settings and addressing settings should be subresoures
> --------------------------------------------------------------------------------------
>
>                 Key: AS7-759
>                 URL: https://issues.jboss.org/browse/AS7-759
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Domain Management, JMS
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 7.1.0.Alpha1
>
>
> otherwise it's not possible to update these settings. If they would be subresources then the generic #add() and #remove() operations would apply.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 13:52:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Jul 2011 13:52:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-702) Expose server VM
 metrics through domain model
In-Reply-To: <373901892.21354.1304083398640.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1067643343.37944.1309974743731.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry resolved AS7-702.
----------------------------------

    Fix Version/s: No Release
                       (was: 7.1.0.Beta1)
       Resolution: Duplicate Issue


Duplicates AS7-340

> Expose server VM metrics through domain model
> ---------------------------------------------
>
>                 Key: AS7-702
>                 URL: https://issues.jboss.org/browse/AS7-702
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: No Release
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 13:54:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Jul 2011 13:54:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-873) Subsystem
 "datasources": attributes not writable
In-Reply-To: <1146255444.18532.1306151700943.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <485775498.37949.1309974863767.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-873:
---------------------------------

    Fix Version/s: 7.1.0.Alpha1
                       (was: 7.1.0.Beta1)


> Subsystem "datasources": attributes not writable
> ------------------------------------------------
>
>                 Key: AS7-873
>                 URL: https://issues.jboss.org/browse/AS7-873
>             Project: Application Server 7
>          Issue Type: Enhancement
>          Components: Domain Management, JCA
>            Reporter: Heiko Braun
>            Assignee: Stefano Maestri
>             Fix For: 7.1.0.Alpha1
>
>
> like this, modifications to datasource configurations are not possible

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 13:54:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Jul 2011 13:54:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-414) Identify operations
 that require restart as part of the operation/attribute description
In-Reply-To: <1776334274.40832.1300743170250.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <537756522.37956.1309974864001.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-414:
---------------------------------

    Fix Version/s: 7.1.0.Alpha1
                       (was: 7.1.0.Beta1)


> Identify operations that require restart as part of the operation/attribute description
> ---------------------------------------------------------------------------------------
>
>                 Key: AS7-414
>                 URL: https://issues.jboss.org/browse/AS7-414
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 7.1.0.Alpha1
>
>
> The implications of an operation with respect to whether invoking it will require a restart (or reload) to take effect should be part of the metadata description of the operation. This makes it possible for things like the console to advise users of the implications of their actions.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 13:56:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Jul 2011 13:56:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-500) Synchronization of
 servers back to the domain following failed operations
In-Reply-To: <944520269.40502.1300735785878.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <972427400.37959.1309974983624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-500:
---------------------------------

    Fix Version/s: 7.1.0.Alpha1
                       (was: 7.1.0.Beta1)


This may not be fully polished, all corner cases covered until a later beta, but we should have the basics covered for 7.1.0.Alpha1.

> Synchronization of servers back to the domain following failed operations
> -------------------------------------------------------------------------
>
>                 Key: AS7-500
>                 URL: https://issues.jboss.org/browse/AS7-500
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 7.1.0.Alpha1
>
>
> Determine strategies for bringing a server back into compliance with the domain following failed operations.
> Simplest is to restart the server.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 14:03:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Jul 2011 14:03:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-793) Expose thread queue
	usage/metrics
In-Reply-To: <276088747.1681.1305552360910.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1916844420.37968.1309975403783.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on AS7-793:
--------------------------------------

We can use this to cover anything from the threads subsystem itself. AS7-340 is for exposing the platform mbeans, which covers the JVM-provided thread metrics.

> Expose thread queue usage/metrics
> ---------------------------------
>
>                 Key: AS7-793
>                 URL: https://issues.jboss.org/browse/AS7-793
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 7.1.0.Beta1
>
>
> I am missing things like current queue size, etc. basically anything that gives you an idea of the load on the system

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 14:03:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 6 Jul 2011 14:03:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1213) Hot deployed lazy
 bundles always activated
Message-ID: <1482169750.37971.1309975403843.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Hot deployed lazy bundles always activated
------------------------------------------

                 Key: AS7-1213
                 URL: https://issues.jboss.org/browse/AS7-1213
             Project: Application Server 7
          Issue Type: Bug
          Components: OSGi
            Reporter: Thomas Diesler
            Assignee: Thomas Diesler




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 14:03:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Jul 2011 14:03:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-340) Expose platform
 mxbeans via the domain model
In-Reply-To: <1224713688.2245.1301949573058.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <306894637.37974.1309975403933.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-340:
---------------------------------

    Fix Version/s: 7.1.0.Alpha1
                       (was: 7.1.0.Beta1)


> Expose platform mxbeans via the domain model
> --------------------------------------------
>
>                 Key: AS7-340
>                 URL: https://issues.jboss.org/browse/AS7-340
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 7.1.0.Alpha1
>
>
> Expose the java.lang.managment MXBeans.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 14:05:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Jul 2011 14:05:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-794) Booting slave host
 controller only makes a single attempt to contact master
In-Reply-To: <111359691.1854.1305556201121.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1966886514.37979.1309975523697.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-794:
---------------------------------

    Fix Version/s: 7.1.0.Alpha1
                       (was: 7.1.0.Beta1)


> Booting slave host controller only makes a single attempt to contact master
> ---------------------------------------------------------------------------
>
>                 Key: AS7-794
>                 URL: https://issues.jboss.org/browse/AS7-794
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 7.1.0.Alpha1
>
>
> RemoteDomainConnectionService tries once to connect; if it fails it gives up immediately and the node switches into slave mode.
> This needs to be more robust, particularly to handle cases where the master and the slave are starting concurrently (i.e. what should ideally be happening in integration tests).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 14:17:23 2011
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Wed, 6 Jul 2011 14:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-9415) Long running thread
 leaks SimpleRole objects
Message-ID: <560743409.38003.1309976243736.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Long running thread leaks SimpleRole objects
--------------------------------------------

                 Key: JBAS-9415
                 URL: https://issues.jboss.org/browse/JBAS-9415
             Project: Legacy JBoss Application Server 6 
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: 6.0.0.Final
         Environment: Tested on Mac OS X 10.6.7 with Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-334, mixed mode) 1.6.0_24
            Reporter: Marcus Moyses
            Assignee: Marcus Moyses
             Fix For: 6.1.0
         Attachments: simpleroletest.tar.gz

When invoking a long-running EJB method which makes a bunch of calls to some method in another EJB, then JBoss leaks SimpleRole objects. The SimpleRole objects are not removed by a manually triggered garbage collection.

The SimpleRole object leakage seems to go away if I remove the security domain in jboss.xml. When running my jboss application during the night JBoss had 4GB of SimpleRole objects.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 14:17:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Jul 2011 14:17:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1102) Create PKCS#11
 Compitable Cryptographic Services for Domain Management
In-Reply-To: <2030558315.16365.1308838704569.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1110090704.38019.1309976244309.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-1102:
----------------------------------

    Fix Version/s: 7.1.0.Alpha1
                       (was: 7.1.0.Beta1)


> Create PKCS#11 Compitable Cryptographic Services for Domain Management
> ----------------------------------------------------------------------
>
>                 Key: AS7-1102
>                 URL: https://issues.jboss.org/browse/AS7-1102
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 7.1.0.Alpha1
>
>
> Within domain management there are occasions where passwords need to be stored or keystores accessed either for encryption / decryption of password or to load the keys used for SSL exchanges.
> Commonly a password within code is used for password based encryption of other passwords, this obfuscates the password but does not over complicate the process of recovering the password, alternatively a local keystore can be used for the encryption but again everything is available on the local disk to recover the password.
> PKCS#11 will allow the cryptographic to be delegated to hardware which contains it's own protection against keys being made available.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 14:17:24 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Wed, 6 Jul 2011 14:17:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1214) Cannot override bind
 address of pbcast.STREAMING_STATE_TRANSFER
Message-ID: <1342587320.38022.1309976244373.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Cannot override bind address of pbcast.STREAMING_STATE_TRANSFER
---------------------------------------------------------------

                 Key: AS7-1214
                 URL: https://issues.jboss.org/browse/AS7-1214
             Project: Application Server 7
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 7.0.0.CR1
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro


You should be able to override the bind_addr by defining a specific socket-binding, however, this only sets the bind_port, not the bind_addr.  That's the bug.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 14:19:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Jul 2011 14:19:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-969) JVM resource
 description doesn't match operation return value
In-Reply-To: <358129882.11862.1307537639575.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <787906069.38028.1309976364036.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-969:
---------------------------------

         Assignee:     (was: Brian Stansberry)
    Fix Version/s: 7.0.1.Final
                       (was: 7.1.0.Beta1)


> JVM resource description doesn't match operation return value
> -------------------------------------------------------------
>
>                 Key: AS7-969
>                 URL: https://issues.jboss.org/browse/AS7-969
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>             Fix For: 7.0.1.Final
>
>
> Reading a JVM resource description returns this:
> {noformat}
> [domain at localhost:9999 /] /server-group=main-server-group/jvm=default:read-resource
> {
>     "outcome" => "success",
>     "result" => {
>         "type" => undefined,
>         "agent-lib" => undefined,
>         "agent-path" => undefined,
>         "env-classpath-ignored" => undefined,
>         "environment-variables" => undefined,
>         "heap-size" => "64m",
>         "max-heap-size" => "512m",
>         "java-agent" => undefined,
>         "java-home" => undefined,
>         "jvm-options" => undefined,
>         "permgen-size" => undefined,
>         "max-permgen-size" => undefined,
>         "stack-size" => undefined
>     },
>     "compensating-operation" => undefined
> }
> {noformat}
> However the resource description looks different.
> It describes certain elements as children, 
> some of the are missing at all ('max-heap-size"')
> {noformat}
> [domain at localhost:9999 /] /server-group=main-server-group/jvm=default:read-resource-description
> {
>     "outcome" => "success",
>     "result" => {
>         "type" => OBJECT,
>         "description" => "The JVM configuration for managed processes / servers.",
>         "attributes" => {
>             "agent-lib" => {
>                 "type" => STRING,
>                 "description" => "The JVM agent lib.",
>                 "access-type" => "read-write",
>                 "storage" => "configuration"
>             },
>             "agent-path" => {
>                 "type" => STRING,
>                 "description" => "The JVM agent path.",
>                 "access-type" => "read-write",
>                 "storage" => "configuration"
>             },
>             "env-classpath-ignored" => {
>                 "type" => BOOLEAN,
>                 "description" => "Ignore the environment classpath.",
>                 "access-type" => "read-write",
>                 "storage" => "configuration"
>             },
>             "environment-variables" => {
>                 "type" => LIST,
>                 "value-type" => UNDEFINED,
>                 "description" => "The JVM environment variables.",
>                 "access-type" => "read-write",
>                 "storage" => "configuration"
>             },
>             "java-agent" => {
>                 "type" => STRING,
>                 "description" => "The java agent.",
>                 "access-type" => "read-write",
>                 "storage" => "configuration"
>             },
>             "java-home" => {
>                 "type" => STRING,
>                 "description" => "The java home",
>                 "access-type" => "read-write",
>                 "storage" => "configuration"
>             },
>             "jvm-options" => {
>                 "type" => LIST,
>                 "value-type" => STRING,
>                 "description" => "The JVM options.",
>                 "access-type" => "read-only",
>                 "storage" => "configuration"
>             },
>             "stack-size" => {
>                 "type" => STRING,
>                 "description" => "The JVM stack size settings.",
>                 "access-type" => "read-write",
>                 "storage" => "configuration"
>             },
>             "type" => {
>                 "type" => STRING,
>                 "description" => "The JVM type can be either SUN or IBM",
>                 "access-type" => "read-only",
>                 "storage" => "configuration"
>             }
>         },
>         "children" => {
>             "heap-size" => {
>                 "type" => OBJECT,
>                 "description" => "The Heap size settings allocated by the JVM.",
>                 "attributes" => {
>                     "size" => STRING,
>                     "max-size" => STRING
>                 }
>             },
>             "permgen-size" => {
>                 "type" => OBJECT,
>                 "description" => "The JVM PermGen settings.",
>                 "attributes" => {
>                     "size" => STRING,
>                     "max-size" => STRING
>                 }
>             }
>         }
>     },
>     "compensating-operation" => undefined
> }
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 14:19:24 2011
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Wed, 6 Jul 2011 14:19:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (SECURITY-603) Long running thread
 leaks SimpleRole objects
In-Reply-To: <560743409.38003.1309976243736.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <680360125.38040.1309976364495.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Marcus Moyses moved JBAS-9415 to SECURITY-603:
----------------------------------------------

              Project: PicketBox (JBoss Security and Identity Management)  (was: Legacy JBoss Application Server 6 )
                  Key: SECURITY-603  (was: JBAS-9415)
    Affects Version/s: PicketBox_v3_0_CR2
                           (was: 6.0.0.Final)
          Component/s: Identity
                           (was: Security)
        Fix Version/s: PicketBox_v4_0_ga
                           (was: 6.1.0)


> Long running thread leaks SimpleRole objects
> --------------------------------------------
>
>                 Key: SECURITY-603
>                 URL: https://issues.jboss.org/browse/SECURITY-603
>             Project: PicketBox (JBoss Security and Identity Management)
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Identity
>    Affects Versions: PicketBox_v3_0_CR2
>         Environment: Tested on Mac OS X 10.6.7 with Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-334, mixed mode) 1.6.0_24
>            Reporter: Marcus Moyses
>            Assignee: Marcus Moyses
>              Labels: jboss
>             Fix For: PicketBox_v4_0_ga
>
>         Attachments: simpleroletest.tar.gz
>
>
> When invoking a long-running EJB method which makes a bunch of calls to some method in another EJB, then JBoss leaks SimpleRole objects. The SimpleRole objects are not removed by a manually triggered garbage collection.
> The SimpleRole object leakage seems to go away if I remove the security domain in jboss.xml. When running my jboss application during the night JBoss had 4GB of SimpleRole objects.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 14:21:23 2011
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Wed, 6 Jul 2011 14:21:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-9362) Long running thread
 leaks SimpleRole objects
In-Reply-To: <163085522.40816.1303282790940.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1961739195.38057.1309976483805.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Marcus Moyses resolved JBAS-9362.
---------------------------------

    Resolution: Done


Fixed for future releases by SECURITY-603

> Long running thread leaks SimpleRole objects
> --------------------------------------------
>
>                 Key: JBAS-9362
>                 URL: https://issues.jboss.org/browse/JBAS-9362
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: 6.0.0.Final
>         Environment: Tested on Mac OS X 10.6.7 with Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-334, mixed mode) 1.6.0_24
>            Reporter: Tim Terlegard
>            Assignee: Marcus Moyses
>              Labels: jboss
>             Fix For: 6.1.0
>
>         Attachments: simpleroletest.tar.gz
>
>
> When invoking a long-running EJB method which makes a bunch of calls to some method in another EJB, then JBoss leaks SimpleRole objects. The SimpleRole objects are not removed by a manually triggered garbage collection.
> The SimpleRole object leakage seems to go away if I remove the security domain in jboss.xml. When running my jboss application during the night JBoss had 4GB of SimpleRole objects.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 14:23:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Wed, 6 Jul 2011 14:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1214) Using specific
 socket-binding does not override bind address for
 pbcast.STREAMING_STATE_TRANSFER
In-Reply-To: <1342587320.38022.1309976244373.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1837184233.38059.1309976603618.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro updated AS7-1214:
------------------------------

                   Summary: Using specific socket-binding does not override bind address for pbcast.STREAMING_STATE_TRANSFER  (was: Cannot override bind address of pbcast.STREAMING_STATE_TRANSFER)
    Workaround Description: 
If you're having connection related state transfer issues, try:

<protocol type="pbcast.STREAMING_STATE_TRANSFER">
   <property name="bind_addr">insert-bind-address-here</property>
</protocol>

or,

<protocol type="pbcast.STREAMING_STATE_TRANSFER">
   <property name="use_default_transport">true</property>
</protocol>

  was:
If you're having connection related state transfer issues, try:
<protocol type="pbcast.STREAMING_STATE_TRANSFER">
   <property name="use_default_transport">true</property>
</protocol>

Or alternatively, define a jgroups.bind_addr system property, which will be picked up by pbcast.STREAMING_STATE_TRANSFER.



> Using specific socket-binding does not override bind address for pbcast.STREAMING_STATE_TRANSFER
> ------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1214
>                 URL: https://issues.jboss.org/browse/AS7-1214
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.CR1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> You should be able to override the bind_addr by defining a specific socket-binding, however, this only sets the bind_port, not the bind_addr.  That's the bug.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 14:25:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Wed, 6 Jul 2011 14:25:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1215)
 pbcast.STREAMING_STATE_TRANSFER should default to use the bind address of
 the transport
Message-ID: <951060406.38063.1309976723720.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

pbcast.STREAMING_STATE_TRANSFER should default to use the bind address of the transport
---------------------------------------------------------------------------------------

                 Key: AS7-1215
                 URL: https://issues.jboss.org/browse/AS7-1215
             Project: Application Server 7
          Issue Type: Bug
            Reporter: Paul Ferraro


Currently, pbcast.STREAMING_STATE_TRANSFER uses an auto-detected bind address, if none was specified.  It should default to the bind address or the transport.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 14:25:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Jul 2011 14:25:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-953) Provide the :reload
 for domain managed servers
In-Reply-To: <916731908.8869.1307454059359.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1856313433.38067.1309976723909.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry resolved AS7-953.
----------------------------------

    Fix Version/s: No Release
                       (was: 7.1.0.Beta1)
       Resolution: Duplicate Issue


Duplicates AS7-947

> Provide the :reload for domain managed servers
> ----------------------------------------------
>
>                 Key: AS7-953
>                 URL: https://issues.jboss.org/browse/AS7-953
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: No Release
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 14:27:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Jul 2011 14:27:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-761) subsystem=web,
 connector=http has no default for executor
In-Reply-To: <546251435.846.1305213211351.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1187058852.38072.1309976843674.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-761:
---------------------------------

    Fix Version/s: 7.1.0.Alpha1
                       (was: 7.1.0.CR1)


> subsystem=web,connector=http has no default for executor
> --------------------------------------------------------
>
>                 Key: AS7-761
>                 URL: https://issues.jboss.org/browse/AS7-761
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management, Web
>            Reporter: Heiko Rupp
>            Assignee: Emanuel Muckenhuber
>             Fix For: 7.1.0.Alpha1
>
>
>    "executor" => {
>                 "type" => STRING,
>                 "description" => "The name of the executor that should be used for the processing threads of this connector. Defaults to using an internal pool.",
>                 "required" => false,
>                 "access-type" => "read-only",
>                 "storage" => "configuration"
>             },

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 14:29:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Jul 2011 14:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-756) Subsystem "jms":
 Attributes are read-only
In-Reply-To: <1578786803.355.1305204391787.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <19289860.38078.1309976963711.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-756:
---------------------------------

    Fix Version/s: 7.1.0.Alpha1
                       (was: 7.1.0.CR1)


> Subsystem "jms": Attributes are read-only
> -----------------------------------------
>
>                 Key: AS7-756
>                 URL: https://issues.jboss.org/browse/AS7-756
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management, JMS
>            Reporter: Heiko Braun
>            Assignee: Emanuel Muckenhuber
>             Fix For: 7.1.0.Alpha1
>
>
> changing queue and topic attributes fails, because all of them are read-only

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 14:29:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Jul 2011 14:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-747) Subsystem "web":
 Boolean model values must not be "undefined"
In-Reply-To: <2055457498.45910.1305116478498.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <578225356.38082.1309976963987.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-747:
---------------------------------

    Fix Version/s: 7.1.0.Alpha1
                       (was: 7.1.0.CR1)


> Subsystem "web": Boolean model values must not be "undefined"
> -------------------------------------------------------------
>
>                 Key: AS7-747
>                 URL: https://issues.jboss.org/browse/AS7-747
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management, Web
>            Reporter: Heiko Braun
>            Assignee: Emanuel Muckenhuber
>             Fix For: 7.1.0.Alpha1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 14:31:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Jul 2011 14:31:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-643) Consistent mechanism
 for masking passwords across the configuration
In-Reply-To: <190113021.18335.1277841286697.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1487704865.38092.1309977083929.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-643:
---------------------------------

    Component/s: Domain Management
                 Security


> Consistent mechanism for masking passwords across the configuration
> -------------------------------------------------------------------
>
>                 Key: AS7-643
>                 URL: https://issues.jboss.org/browse/AS7-643
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Domain Management, Security
>            Reporter: Brian Stansberry
>             Fix For: 7.1.0.Alpha1
>
>
> This JIRA is based on feedback we received after the Andiamo BOF at JBoss World 2010: 
> >> The means to mask passwords is different for
> >> the newer jboss-beans.xml files from the older mbean
> >> configurations. Would much rather have a one and done solution
> >> instead of managing two different solutions.
> With the AS 7 unified domain configuration this should fall out naturally, but we need to guard that no subsystems introduce non-standard ways of doing this.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 14:31:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Jul 2011 14:31:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-639) Common mechanism for
 all secure socket definitions
In-Reply-To: <2117903103.18320.1277840626484.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <167503622.38094.1309977083995.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-639:
---------------------------------

    Component/s: Domain Management


> Common mechanism for all secure socket definitions
> --------------------------------------------------
>
>                 Key: AS7-639
>                 URL: https://issues.jboss.org/browse/AS7-639
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 7.1.0.Alpha1
>
>
> This JIRA is based on feedback we received after the Andiamo BOF at JBoss World 2010:
> >> The JAASSecurityDomain in my opinion should
> >> handle all secure socket definitions. Mod-cluster currently does
> >> not support JAASSecurityDomains.
> I won't comment either way on whether JAASSecurityDomain is how we'll do this, but I definitely agree that a common mechanism should be used for all secure socket definitions.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 14:32:34 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Jul 2011 14:32:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-821) Fix or remove @Ignore
 in StandardConfigsXMLValidationUnitTestCase
In-Reply-To: <52242124.6979.1305665641123.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <459603004.38101.1309977154412.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry resolved AS7-821.
----------------------------------

    Fix Version/s: 7.0.0.CR1
                       (was: 7.1.0.Alpha1)
       Resolution: Done


> Fix or remove @Ignore in StandardConfigsXMLValidationUnitTestCase
> -----------------------------------------------------------------
>
>                 Key: AS7-821
>                 URL: https://issues.jboss.org/browse/AS7-821
>             Project: Application Server 7
>          Issue Type: Sub-task
>            Reporter: Thomas Diesler
>            Assignee: John Bailey
>             Fix For: 7.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 14:34:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Jul 2011 14:34:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-280) Missing service
 dependencies doesn't result in deployment failure
In-Reply-To: <701537675.22249.1300081255462.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <654759449.38107.1309977263773.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry resolved AS7-280.
----------------------------------

    Fix Version/s: 7.0.0.CR1
                       (was: 7.1.0.Alpha1)
       Resolution: Done


Should have been fixed in 7.0.0.CR1; please re-open if not.

> Missing service dependencies doesn't result in deployment failure
> -----------------------------------------------------------------
>
>                 Key: AS7-280
>                 URL: https://issues.jboss.org/browse/AS7-280
>             Project: Application Server 7
>          Issue Type: Bug
>         Environment: JBoss AS7 trunk 
>            Reporter: jaikiran pai
>             Fix For: 7.0.0.CR1
>
>
> Like discussed in this mailing list thread http://lists.jboss.org/pipermail/jboss-as7-dev/2011-February/000466.html currently if a deployment has missing service dependencies, it *doesn't* trigger a deployment failure. As a result, the runtime invocation on the component results in exceptions (which are a side-effect of deployment issues).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 14:34:24 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Wed, 6 Jul 2011 14:34:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1214) Using specific
 socket-binding does not override bind address for
 pbcast.STREAMING_STATE_TRANSFER
In-Reply-To: <1342587320.38022.1309976244373.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1940524063.38114.1309977264023.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro updated AS7-1214:
------------------------------

    Description: You should be able to override the bind_addr and bind_port by defining a specific socket-binding, however, this doesn't work.  (was: You should be able to override the bind_addr by defining a specific socket-binding, however, this only sets the bind_port, not the bind_addr.  That's the bug.)


> Using specific socket-binding does not override bind address for pbcast.STREAMING_STATE_TRANSFER
> ------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1214
>                 URL: https://issues.jboss.org/browse/AS7-1214
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.CR1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> You should be able to override the bind_addr and bind_port by defining a specific socket-binding, however, this doesn't work.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 14:36:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 6 Jul 2011 14:36:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-996) distro dir should be
 jboss-as-* not just jboss-*
In-Reply-To: <339346472.19226.1307716620186.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1429414463.38120.1309977383745.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-996:
---------------------------------

       Fix Version/s: 7.0.0.Final
                          (was: 7.1.0.Alpha1)
    Git Pull Request: https://github.com/jbossas/jboss-as/pull/53  (was: https://github.com/jbossas/jboss-as/pull/53)


Assigning to 7.0.0.Final only because I think this was done?

> distro dir should be jboss-as-* not just jboss-*
> ------------------------------------------------
>
>                 Key: AS7-996
>                 URL: https://issues.jboss.org/browse/AS7-996
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: Max Rydahl Andersen
>            Assignee: Jason Greene
>             Fix For: 7.0.0.Final
>
>
> current build script generates a distro named jboss-* where it should be jboss-as-*

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 14:36:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Wed, 6 Jul 2011 14:36:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1215)
 pbcast.STREAMING_STATE_TRANSFER should default to use the bind address of
 the transport
In-Reply-To: <951060406.38063.1309976723720.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1356426003.38125.1309977383921.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro reassigned AS7-1215:
---------------------------------

    Assignee: Paul Ferraro


> pbcast.STREAMING_STATE_TRANSFER should default to use the bind address of the transport
> ---------------------------------------------------------------------------------------
>
>                 Key: AS7-1215
>                 URL: https://issues.jboss.org/browse/AS7-1215
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> Currently, pbcast.STREAMING_STATE_TRANSFER uses an auto-detected bind address, if none was specified.  It should default to the bind address or the transport.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 14:42:23 2011
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Wed, 6 Jul 2011 14:42:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (SECURITY-603) Long running
 thread leaks SimpleRole objects
In-Reply-To: <560743409.38003.1309976243736.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1210256351.38132.1309977743692.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Marcus Moyses resolved SECURITY-603.
------------------------------------

    Resolution: Done


The memory leak was present in SimpleRoleGroup. It stores SimpleRoles in an ArrayList and there was multiple entries for the same role there. Fixed by only adding new roles to the ArrayList.

> Long running thread leaks SimpleRole objects
> --------------------------------------------
>
>                 Key: SECURITY-603
>                 URL: https://issues.jboss.org/browse/SECURITY-603
>             Project: PicketBox (JBoss Security and Identity Management)
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Identity
>    Affects Versions: PicketBox_v3_0_CR2
>         Environment: Tested on Mac OS X 10.6.7 with Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-334, mixed mode) 1.6.0_24
>            Reporter: Marcus Moyses
>            Assignee: Marcus Moyses
>              Labels: jboss
>             Fix For: PicketBox_v4_0_ga
>
>         Attachments: simpleroletest.tar.gz
>
>
> When invoking a long-running EJB method which makes a bunch of calls to some method in another EJB, then JBoss leaks SimpleRole objects. The SimpleRole objects are not removed by a manually triggered garbage collection.
> The SimpleRole object leakage seems to go away if I remove the security domain in jboss.xml. When running my jboss application during the night JBoss had 4GB of SimpleRole objects.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 14:44:23 2011
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Wed, 6 Jul 2011 14:44:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-604) Release PicketBox
	4.0.0.Final
Message-ID: <139968030.38137.1309977863661.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Release PicketBox 4.0.0.Final
-----------------------------

                 Key: SECURITY-604
                 URL: https://issues.jboss.org/browse/SECURITY-604
             Project: PicketBox (JBoss Security and Identity Management)
          Issue Type: Release
      Security Level: Public (Everyone can see)
          Components: PicketBox
    Affects Versions: PicketBox_v4_0_cr1
            Reporter: Marcus Moyses
            Assignee: Marcus Moyses
             Fix For: PicketBox_v4_0_final


New release for AS7 GA

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 15:13:23 2011
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Wed, 6 Jul 2011 15:13:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (SECURITY-604) Release
	PicketBox 4.0.0.Final
In-Reply-To: <139968030.38137.1309977863661.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <861101846.38164.1309979603649.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Marcus Moyses resolved SECURITY-604.
------------------------------------

    Resolution: Done


Released

> Release PicketBox 4.0.0.Final
> -----------------------------
>
>                 Key: SECURITY-604
>                 URL: https://issues.jboss.org/browse/SECURITY-604
>             Project: PicketBox (JBoss Security and Identity Management)
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>          Components: PicketBox
>    Affects Versions: PicketBox_v4_0_cr1
>            Reporter: Marcus Moyses
>            Assignee: Marcus Moyses
>             Fix For: PicketBox_v4_0_final
>
>
> New release for AS7 GA

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 15:17:23 2011
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Wed, 6 Jul 2011 15:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1195) Failure to load
 login-module should be reported as WARNING instead of TRACE
In-Reply-To: <604271086.36476.1309909524203.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <17644595.38173.1309979843903.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Marcus Moyses resolved AS7-1195.
--------------------------------

    Fix Version/s: 7.0.1.Final
       Resolution: Done


Fixed by changing PB jar version to 4.0.0.Final

> Failure to load login-module should be reported as WARNING instead of TRACE
> ---------------------------------------------------------------------------
>
>                 Key: AS7-1195
>                 URL: https://issues.jboss.org/browse/AS7-1195
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Security
>    Affects Versions: 7.0.0.CR1
>         Environment: java-6-sun-1.6.0.24
> Linux ubuntu 
>            Reporter: Bruno Vernay
>            Assignee: Marcus Moyses
>             Fix For: 7.0.1.Final
>
>
> An error in standalone.xml :
> <security-domains>              
>  <security-domain ...>
>   <authentication>
>    <login-module code="database" flag="required">
> is reported in TRACE: 
> TRACE [org.jboss.security.authentication.JBossCachedAuthenticationManager] (http--127.0.0.1-8080-1) Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: database from [Module "deployment.jboss-as-login.war:main" from Service Module Loader]
> It makes it difficult to spot the error. 
> Would be easier if it was reported as a WARNING, specially since it is "required"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 15:19:23 2011
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Wed, 6 Jul 2011 15:19:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1195) Failure to load
 login-module should be reported as WARNING instead of TRACE
In-Reply-To: <604271086.36476.1309909524203.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <251471268.38179.1309979963795.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Marcus Moyses commented on AS7-1195:
------------------------------------

https://github.com/mmoyses/jboss-as/commit/d66625f808b070133ae5a9f3cb1edd98e2de8e0c

> Failure to load login-module should be reported as WARNING instead of TRACE
> ---------------------------------------------------------------------------
>
>                 Key: AS7-1195
>                 URL: https://issues.jboss.org/browse/AS7-1195
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Security
>    Affects Versions: 7.0.0.CR1
>         Environment: java-6-sun-1.6.0.24
> Linux ubuntu 
>            Reporter: Bruno Vernay
>            Assignee: Marcus Moyses
>             Fix For: 7.0.1.Final
>
>
> An error in standalone.xml :
> <security-domains>              
>  <security-domain ...>
>   <authentication>
>    <login-module code="database" flag="required">
> is reported in TRACE: 
> TRACE [org.jboss.security.authentication.JBossCachedAuthenticationManager] (http--127.0.0.1-8080-1) Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: database from [Module "deployment.jboss-as-login.war:main" from Service Module Loader]
> It makes it difficult to spot the error. 
> Would be easier if it was reported as a WARNING, specially since it is "required"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 16:23:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 6 Jul 2011 16:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-620) PicketBox 4.0.0.Final
In-Reply-To: <1053123638.37810.1309969163706.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <965137003.38277.1309983803668.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen updated JBJCA-620:
----------------------------------

    Summary: PicketBox 4.0.0.Final  (was: PicketBox 4.0.0.CR1)


> PicketBox 4.0.0.Final
> ---------------------
>
>                 Key: JBJCA-620
>                 URL: https://issues.jboss.org/browse/JBJCA-620
>             Project: IronJacamar
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.1.0.Alpha1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 16:23:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 6 Jul 2011 16:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-614) PicketBox 4.0.0.Final
In-Reply-To: <830823337.37781.1309968683840.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <791052999.38279.1309983803711.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen updated JBJCA-614:
----------------------------------

    Summary: PicketBox 4.0.0.Final  (was: PicketBox 4.0.0.CR1)


> PicketBox 4.0.0.Final
> ---------------------
>
>                 Key: JBJCA-614
>                 URL: https://issues.jboss.org/browse/JBJCA-614
>             Project: IronJacamar
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 16:37:23 2011
From: jira-events at lists.jboss.org (Justin Bertram (JIRA))
Date: Wed, 6 Jul 2011 16:37:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1884)
 ClientTransaction alters wire format
In-Reply-To: <986237120.37710.1309967543969.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <82646886.38292.1309984643669.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Justin Bertram updated JBMESSAGING-1884:
----------------------------------------

    Description: 
JBMESSAGING-1786 changed the format of ClientTransaction to include a recovery flag, unfortunately this breaks the wire protocol with older clients.

The versions containing the problematic changes from JBMESSAGING-1786 are
  - 1.4.0 SP3 CP11, CP12, CP13
  - 1.4.6 GA SP1
  - 1.4.7 GA
  - 1.4.8 GA
  - 1.4.8 SP1

Attached to this issue is a diff, made against the current Branch_1_4, which addresses the issue.

Older clients should still be able to talk to the newer server but will not be able to take advantage of the fix for JBMESSAGING-1786.

  was:
JBMESSAGING-1786 changed the format of ClientTransaction to include a recovery flag, unfortunately this breaks the wire protocol with older clients.

The versions containing this problem are
  - 1.4.0 SP3 CP11, CP12, CP13
  - 1.4.6 GA SP1
  - 1.4.7 GA
  - 1.4.8 GA
  - 1.4.8 SP1

Attached to this issue is a diff, made against the current Branch_1_4, which addresses the issue.

Older clients should still be able to talk to the newer server but will not be able to take advantage of the fix for JBMESSAGING-1786.



> ClientTransaction alters wire format
> ------------------------------------
>
>                 Key: JBMESSAGING-1884
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1884
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.8.SP1
>            Reporter: Kevin Conner
>            Assignee: Justin Bertram
>         Attachments: transaction.diffs
>
>
> JBMESSAGING-1786 changed the format of ClientTransaction to include a recovery flag, unfortunately this breaks the wire protocol with older clients.
> The versions containing the problematic changes from JBMESSAGING-1786 are
>   - 1.4.0 SP3 CP11, CP12, CP13
>   - 1.4.6 GA SP1
>   - 1.4.7 GA
>   - 1.4.8 GA
>   - 1.4.8 SP1
> Attached to this issue is a diff, made against the current Branch_1_4, which addresses the issue.
> Older clients should still be able to talk to the newer server but will not be able to take advantage of the fix for JBMESSAGING-1786.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 16:52:24 2011
From: jira-events at lists.jboss.org (Justin Bertram (JIRA))
Date: Wed, 6 Jul 2011 16:52:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1884)
 ClientTransaction alters wire format
In-Reply-To: <986237120.37710.1309967543969.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1523177774.38308.1309985544026.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Justin Bertram updated JBMESSAGING-1884:
----------------------------------------

             Affects Version/s: 1.4.8.GA
                                1.4.7.GA
                                1.4.6.GA.SP1
                                1.4.0.SP3.CP13
                                1.4.0.SP3.CP12
                                1.4.0.SP3.CP11
                   Description: 
JBMESSAGING-1786 changed the format of ClientTransaction to include a recovery flag, unfortunately this breaks the wire protocol with older clients.

The versions containing the problematic changes from JBMESSAGING-1786 are
  - 1.4.0 SP3 CP11, CP12, CP13
  - 1.4.6 GA SP1
  - 1.4.7 GA
  - 1.4.8 GA
  - 1.4.8 SP1

Clients communicating with one of these versions of JBoss Messaging using libraries from any version aside from these will have problems performing transactions (i.e. network communication will hang because each side will be expecting different data).

Attached to this issue is a diff, made against the current Branch_1_4, which addresses the issue.

Older clients should still be able to talk to the newer server but will not be able to take advantage of the fix for JBMESSAGING-1786.

  was:
JBMESSAGING-1786 changed the format of ClientTransaction to include a recovery flag, unfortunately this breaks the wire protocol with older clients.

The versions containing the problematic changes from JBMESSAGING-1786 are
  - 1.4.0 SP3 CP11, CP12, CP13
  - 1.4.6 GA SP1
  - 1.4.7 GA
  - 1.4.8 GA
  - 1.4.8 SP1

Attached to this issue is a diff, made against the current Branch_1_4, which addresses the issue.

Older clients should still be able to talk to the newer server but will not be able to take advantage of the fix for JBMESSAGING-1786.



> ClientTransaction alters wire format
> ------------------------------------
>
>                 Key: JBMESSAGING-1884
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1884
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP11, 1.4.0.SP3.CP12, 1.4.0.SP3.CP13, 1.4.6.GA.SP1, 1.4.7.GA, 1.4.8.GA, 1.4.8.SP1
>            Reporter: Kevin Conner
>            Assignee: Justin Bertram
>         Attachments: transaction.diffs
>
>
> JBMESSAGING-1786 changed the format of ClientTransaction to include a recovery flag, unfortunately this breaks the wire protocol with older clients.
> The versions containing the problematic changes from JBMESSAGING-1786 are
>   - 1.4.0 SP3 CP11, CP12, CP13
>   - 1.4.6 GA SP1
>   - 1.4.7 GA
>   - 1.4.8 GA
>   - 1.4.8 SP1
> Clients communicating with one of these versions of JBoss Messaging using libraries from any version aside from these will have problems performing transactions (i.e. network communication will hang because each side will be expecting different data).
> Attached to this issue is a diff, made against the current Branch_1_4, which addresses the issue.
> Older clients should still be able to talk to the newer server but will not be able to take advantage of the fix for JBMESSAGING-1786.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 16:54:23 2011
From: jira-events at lists.jboss.org (Justin Bertram (JIRA))
Date: Wed, 6 Jul 2011 16:54:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMESSAGING-1884)
 ClientTransaction alters wire format
In-Reply-To: <986237120.37710.1309967543969.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1293989702.38318.1309985663985.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Justin Bertram resolved JBMESSAGING-1884.
-----------------------------------------

    Resolution: Done


Applied the patch and committed.

> ClientTransaction alters wire format
> ------------------------------------
>
>                 Key: JBMESSAGING-1884
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1884
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP11, 1.4.0.SP3.CP12, 1.4.0.SP3.CP13, 1.4.6.GA.SP1, 1.4.7.GA, 1.4.8.GA, 1.4.8.SP1
>            Reporter: Kevin Conner
>            Assignee: Justin Bertram
>         Attachments: transaction.diffs
>
>
> JBMESSAGING-1786 changed the format of ClientTransaction to include a recovery flag, unfortunately this breaks the wire protocol with older clients.
> The versions containing the problematic changes from JBMESSAGING-1786 are
>   - 1.4.0 SP3 CP11, CP12, CP13
>   - 1.4.6 GA SP1
>   - 1.4.7 GA
>   - 1.4.8 GA
>   - 1.4.8 SP1
> Clients communicating with one of these versions of JBoss Messaging using libraries from any version aside from these will have problems performing transactions (i.e. network communication will hang because each side will be expecting different data).
> Attached to this issue is a diff, made against the current Branch_1_4, which addresses the issue.
> Older clients should still be able to talk to the newer server but will not be able to take advantage of the fix for JBMESSAGING-1786.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 16:54:24 2011
From: jira-events at lists.jboss.org (Justin Bertram (JIRA))
Date: Wed, 6 Jul 2011 16:54:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1884)
 ClientTransaction alters wire format
In-Reply-To: <986237120.37710.1309967543969.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <843560548.38323.1309985664157.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Justin Bertram updated JBMESSAGING-1884:
----------------------------------------

    Fix Version/s: 1.4.0.SP3.CP14
                   1.4.8.SP2


> ClientTransaction alters wire format
> ------------------------------------
>
>                 Key: JBMESSAGING-1884
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1884
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP11, 1.4.0.SP3.CP12, 1.4.0.SP3.CP13, 1.4.6.GA.SP1, 1.4.7.GA, 1.4.8.GA, 1.4.8.SP1
>            Reporter: Kevin Conner
>            Assignee: Justin Bertram
>             Fix For: 1.4.0.SP3.CP14, 1.4.8.SP2
>
>         Attachments: transaction.diffs
>
>
> JBMESSAGING-1786 changed the format of ClientTransaction to include a recovery flag, unfortunately this breaks the wire protocol with older clients.
> The versions containing the problematic changes from JBMESSAGING-1786 are
>   - 1.4.0 SP3 CP11, CP12, CP13
>   - 1.4.6 GA SP1
>   - 1.4.7 GA
>   - 1.4.8 GA
>   - 1.4.8 SP1
> Clients communicating with one of these versions of JBoss Messaging using libraries from any version aside from these will have problems performing transactions (i.e. network communication will hang because each side will be expecting different data).
> Attached to this issue is a diff, made against the current Branch_1_4, which addresses the issue.
> Older clients should still be able to talk to the newer server but will not be able to take advantage of the fix for JBMESSAGING-1786.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul  6 18:47:23 2011
From: jira-events at lists.jboss.org (Drew Stockdreher (JIRA))
Date: Wed, 6 Jul 2011 18:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1216)
 NonexistentConversationException when attempting to restore a long-running
 conversation on AS 7 CR1 and not beta3
Message-ID: <1250756013.38439.1309992443679.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

NonexistentConversationException when attempting to restore a long-running conversation on AS 7 CR1 and not beta3
-----------------------------------------------------------------------------------------------------------------

                 Key: AS7-1216
                 URL: https://issues.jboss.org/browse/AS7-1216
             Project: Application Server 7
          Issue Type: Bug
          Components: CDI / Weld
    Affects Versions: 7.0.0.CR1
         Environment: Windows XP 32 bit, JBoss AS 7 CR1 and Firefox 5
            Reporter: Drew Stockdreher


A simple web application which starts a long-running conversation via an 

<f:event type="preRenderView" listener="#{bean.startConvo}"/> tag. 

 Selecting from a selectOneMenuList makes an ajax request which was working on the beta3 release of AS 7 is no longer working with the following stacktrace.  This does however still work in IE 7 and Chrome 12 on both beta3 and CR1 releases. 

10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1) org.jboss.weld.context.NonexistentConversationException: WELD-000321 No conversation found to restore for id 1
10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.jboss.weld.jsf.WeldPhaseListener.activateConversations(WeldPhaseListener.java:108)
10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.jboss.weld.jsf.WeldPhaseListener.beforePhase(WeldPhaseListener.java:84)
10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1)    at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228)
10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1)    at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99)
10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1)    at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:111)
10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1)    at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1)    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312)
10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67)
10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49)
10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
10:36:11,322 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
10:36:11,322 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667)
10:36:11,322 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951)
10:36:11,322 ERROR [stderr] (http--127.0.0.1-8080-1)    at java.lang.Thread.run(Thread.java:662)


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 01:20:40 2011
From: jira-events at lists.jboss.org (Sandeep T H (JIRA))
Date: Thu, 7 Jul 2011 01:20:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1343) JGroups 2.6.2
 hangs during JChannel.connect
In-Reply-To: <219174054.37442.1309960403679.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1413891924.38831.1310016040674.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Sandeep T H commented on JGRP-1343:
-----------------------------------

We are also using the JBoss Cache 2.1.0 with which the compatible versions of JGroups is 2.6.2.
Could you suggest anything else that we could try?

> JGroups 2.6.2 hangs during JChannel.connect
> -------------------------------------------
>
>                 Key: JGRP-1343
>                 URL: https://issues.jboss.org/browse/JGRP-1343
>             Project: JGroups
>          Issue Type: Quality Risk
>    Affects Versions: 2.6.2
>         Environment: Linux, cluster
>            Reporter: Sandeep T H
>            Assignee: Bela Ban
>
> In a cluster having two nodes A & B, A is up and running and when B is started for the first time it sometimes hangs in JChannel.connect.
> If we bring down A then B is able to resume and connect. This issue happens randomly but frequently.
> Please let us know if we have missed something or need something.
> The jgroups configuration used is :
> <config>
>     <UDP
>          mcast_addr="${jgroups.udp.mcast_addr:224.0.0.0}"
>          mcast_port="${jgroups.udp.mcast_port:$JGroup_port}"
>          tos="8"
>          ucast_recv_buf_size="20000000"
>          ucast_send_buf_size="640000"
>          mcast_recv_buf_size="25000000"
>          mcast_send_buf_size="640000"
>          loopback="false"
>          discard_incompatible_packets="true"
>          max_bundle_size="64000"
>          max_bundle_timeout="30"
>          use_incoming_packet_handler="true"
>          ip_ttl="${jgroups.udp.ip_ttl:2}"
>          enable_bundling="true"
>          enable_diagnostics="true"
>          thread_naming_pattern="cl"
>          use_concurrent_stack="true"
>          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="1000"
>          thread_pool.rejection_policy="Run"
>          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="Run"/>
>     <PING timeout="2000"
>             num_initial_members="3"/>
>     <MERGE2 max_interval="30000"
>             min_interval="10000"/>
>     <FD_SOCK/>
>     <FD timeout="10000" max_tries="5"   shun="true"/>
>     <VERIFY_SUSPECT timeout="1500"  />
>     <BARRIER />
>     <pbcast.NAKACK use_stats_for_retransmission="false"
>                    exponential_backoff="150"
>                    use_mcast_xmit="true" gc_lag="0"
>                    retransmit_timeout="50,300,600,1200"
>                    discard_delivered_msgs="true"/>
>     <UNICAST timeout="300,600,1200"/>
>     <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
>                    max_bytes="1000000"/>
>     <VIEW_SYNC avg_send_interval="60000"   />
>     <pbcast.GMS print_local_addr="true" join_timeout="5000"
>                 shun="false"
>                 view_bundling="true"/>
>     <FC max_credits="500000"
>                     min_threshold="0.20"/>
>     <FRAG2 frag_size="60000"  />
>     <pbcast.STREAMING_STATE_TRANSFER />
> <!--    <pbcast.STATE_TRANSFER  />-->
>     <pbcast.FLUSH timeout="0"/>
> </config>

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 01:55:23 2011
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 7 Jul 2011 01:55:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1343) JGroups 2.6.2
 hangs during JChannel.connect
In-Reply-To: <219174054.37442.1309960403679.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <616489474.38901.1310018123705.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1343:
--------------------------------

JGroups 2.6.15 should be backward compatible with 2.6.2, so you could just upgrade the JGroups JAR. If your project allows you to, you can of course always upgrade to Infinispan/JGroups. Infinispan is the successor to JBossCache.

> JGroups 2.6.2 hangs during JChannel.connect
> -------------------------------------------
>
>                 Key: JGRP-1343
>                 URL: https://issues.jboss.org/browse/JGRP-1343
>             Project: JGroups
>          Issue Type: Quality Risk
>    Affects Versions: 2.6.2
>         Environment: Linux, cluster
>            Reporter: Sandeep T H
>            Assignee: Bela Ban
>
> In a cluster having two nodes A & B, A is up and running and when B is started for the first time it sometimes hangs in JChannel.connect.
> If we bring down A then B is able to resume and connect. This issue happens randomly but frequently.
> Please let us know if we have missed something or need something.
> The jgroups configuration used is :
> <config>
>     <UDP
>          mcast_addr="${jgroups.udp.mcast_addr:224.0.0.0}"
>          mcast_port="${jgroups.udp.mcast_port:$JGroup_port}"
>          tos="8"
>          ucast_recv_buf_size="20000000"
>          ucast_send_buf_size="640000"
>          mcast_recv_buf_size="25000000"
>          mcast_send_buf_size="640000"
>          loopback="false"
>          discard_incompatible_packets="true"
>          max_bundle_size="64000"
>          max_bundle_timeout="30"
>          use_incoming_packet_handler="true"
>          ip_ttl="${jgroups.udp.ip_ttl:2}"
>          enable_bundling="true"
>          enable_diagnostics="true"
>          thread_naming_pattern="cl"
>          use_concurrent_stack="true"
>          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="1000"
>          thread_pool.rejection_policy="Run"
>          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="Run"/>
>     <PING timeout="2000"
>             num_initial_members="3"/>
>     <MERGE2 max_interval="30000"
>             min_interval="10000"/>
>     <FD_SOCK/>
>     <FD timeout="10000" max_tries="5"   shun="true"/>
>     <VERIFY_SUSPECT timeout="1500"  />
>     <BARRIER />
>     <pbcast.NAKACK use_stats_for_retransmission="false"
>                    exponential_backoff="150"
>                    use_mcast_xmit="true" gc_lag="0"
>                    retransmit_timeout="50,300,600,1200"
>                    discard_delivered_msgs="true"/>
>     <UNICAST timeout="300,600,1200"/>
>     <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
>                    max_bytes="1000000"/>
>     <VIEW_SYNC avg_send_interval="60000"   />
>     <pbcast.GMS print_local_addr="true" join_timeout="5000"
>                 shun="false"
>                 view_bundling="true"/>
>     <FC max_credits="500000"
>                     min_threshold="0.20"/>
>     <FRAG2 frag_size="60000"  />
>     <pbcast.STREAMING_STATE_TRANSFER />
> <!--    <pbcast.STATE_TRANSFER  />-->
>     <pbcast.FLUSH timeout="0"/>
> </config>

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 02:20:23 2011
From: jira-events at lists.jboss.org (James Livingston (JIRA))
Date: Thu, 7 Jul 2011 02:20:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1217) Deployment fails when
 deployment-scanner is pointed to UNC path
Message-ID: <1720763021.38971.1310019623626.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Deployment fails when deployment-scanner is pointed to UNC path
---------------------------------------------------------------

                 Key: AS7-1217
                 URL: https://issues.jboss.org/browse/AS7-1217
             Project: Application Server 7
          Issue Type: Bug
    Affects Versions: 7.0.0.CR1
            Reporter: James Livingston


On JBoss 5, you could add an additional deployment directory located via a UNC path (\\computername\share on Windows). On AS 7.0.0.CR1 it detects that a deployment has been added, but fails deployment because a backslash character gets lost between the host and share parts of the path.

To reproduce:
1) share a directory on a Windows machine, for example "share" on the machine "host"
2) In standalone.xml, add a deployment-scanner with the path "\\host\share\" (or "\\\\host\\share", escaping the backshashes doesn't make a difference)
3) Put a WAR file in that directory
4) start JBoss

It will fail with the error:

ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC00001: Failed to start service jboss.deployment.unit."sample.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."sample.war".STRU
CTURE: Failed to process phase STRUCTURE of deployment "sample.war"
        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
        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(Unknown Source) [:1.6.0_24]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [:1.6.0_24]
        at java.lang.Thread.run(Unknown Source) [:1.6.0_24]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to mount deployment content
        at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:82)
        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
        ... 5 more
Caused by: java.io.FileNotFoundException: \\hostshare\sample.war (The network path was not found)
        at java.io.FileInputStream.open(Native Method) [:1.6.0_24]
        at java.io.FileInputStream.<init>(Unknown Source) [:1.6.0_24]
        at org.jboss.vfs.spi.RootFileSystem.openInputStream(RootFileSystem.java:55)
        at org.jboss.vfs.VirtualFile.openStream(VirtualFile.java:238)
        at org.jboss.vfs.VFS.mountZipExpanded(VFS.java:567)
        at org.jboss.as.server.deployment.repository.impl.ServerDeploymentRepositoryImpl.mountDeploymentContent(ServerDeploymentRepositoryImpl.java:73)
        at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:78)
        ... 6 more

05:47:04,303 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 2) Deployment of "sample.war" was rolled back with failure message {"Failed services" => {"jboss.deployment.unit.\"sample.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"sample.war\".STRUCTURE: Failed to process phase STRUCTURE of deployment \"sample.war\""}}


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 03:23:23 2011
From: jira-events at lists.jboss.org (Artur Karpinski (JIRA))
Date: Thu, 7 Jul 2011 03:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1841) JBM_MSG_REF
 primary key update performance issue (possible timeout/failure)
In-Reply-To: <1292097997.12524.1294948789646.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1121817866.39037.1310023403811.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Artur Karpinski commented on JBMESSAGING-1841:
----------------------------------------------

We are experiencing similar performance problem on Oracle database. Modifying primary key is expensive operation and creates problems when you want to optimize things on database.

> JBM_MSG_REF primary key update performance issue (possible timeout/failure)
> ---------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1841
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1841
>             Project: JBoss Messaging
>          Issue Type: Enhancement
>          Components: JMS Clustering, Messaging Core Persistence
>    Affects Versions: 1.4.3.GA
>         Environment: JBoss 5.1.0.GA in "all" configuration, PostOffice has FailoverOnNodeLeave = true, using MySQL Cluster 7.1.9a backend (ndb-persistence-service.xml)
>            Reporter: Gerald Turner
>            Assignee: Yong Hao Gao
>
> The JBM_MSG_REF table has primary key MESSAGE_ID+CHANNEL_ID.
> On cluster node failover a statement is run that changes CHANNEL_ID, thus modifies the primary key - an expensive operation.
>   UPDATE JBM_MSG_REF SET CHANNEL_ID = ? WHERE CHANNEL_ID = ?
> I'm using a pair of hefty servers for NDB storage node backends (16 CPUs, 8GB RAM dedicated to NDB process, no other processess).  I've witnessed this update statement taking around 90 seconds with 70,000 messages in queue, and 180 seconds with 140,000 messages in queue.  Our MySQL DataSource connections had parameter socketTimeout 30000, causing the failover process to rollback and retry several times until giving up, crashing the PostOffice.  This timeout parameter can easily be changed or removed (block forever?), but failover still takes a very long time.
> I altered the JBM_MSG_REF table so that MESSAGE_ID is the only part of the primary key.  This makes the failover CHANNEL_ID update statement run instantly.  I can't imagine a case where the JBM_MSG_REF would have duplicate MESSAGE_ID rows.  If this is reasonable, could the next release of jboss-messaging 1.4.x drop CHANNEL_ID from the primary key of the CREATE TABLE JBM_MSG_REF statement?  Otherwise please let me know if this table alteration is unsafe.
> In particular, I changed one line of ndb-persistence-service.xml SqlProperties parameter, from:
>    CREATE_MESSAGE_REFERENCE=CREATE TABLE JBM_MSG_REF (MESSAGE_ID BIGINT, CHANNEL_ID BIGINT, TRANSACTION_ID BIGINT, STATE CHAR(1), ORD BIGINT, PAGE_ORD BIGINT, DELIVERY_COUNT INTEGER, SCHED_DELIVERY BIGINT, PRIMARY KEY(MESSAGE_ID, CHANNEL_ID)) ENGINE = NDBCLUSTER
> to:
>    CREATE_MESSAGE_REFERENCE=CREATE TABLE JBM_MSG_REF (MESSAGE_ID BIGINT, CHANNEL_ID BIGINT, TRANSACTION_ID BIGINT, STATE CHAR(1), ORD BIGINT, PAGE_ORD BIGINT, DELIVERY_COUNT INTEGER, SCHED_DELIVERY BIGINT, PRIMARY KEY(MESSAGE_ID)) ENGINE = NDBCLUSTER

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 03:25:23 2011
From: jira-events at lists.jboss.org (santhosh ganapathi (JIRA))
Date: Thu, 7 Jul 2011 03:25:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-9414) Run time exception
 in Jboss 6 - org.jboss.cache.CacheException:
 java.lang.reflect.InvocationTargetException
In-Reply-To: <1676472132.37210.1309953083660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <823754876.39040.1310023523829.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

santhosh ganapathi commented on JBAS-9414:
------------------------------------------

Hi Jaikiran,

Thanks for your reply. I created the forum thread. Kindly, look into this and advise me.

Forum Thread url : http://community.jboss.org/thread/169062

Thanks.

> Run time exception in Jboss 6 - org.jboss.cache.CacheException: java.lang.reflect.InvocationTargetException
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-9414
>                 URL: https://issues.jboss.org/browse/JBAS-9414
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>         Environment: Windows xp OS, Jboss 6 with JDK 1.6, Hibernate 3.2.0.
>            Reporter: santhosh ganapathi
>              Labels: jboss
>
> 15:29:42,059 ERROR [STDERR] org.jboss.cache.CacheException: java.lang.reflect.InvocationTargetException
> 15:29:42,059 ERROR [STDERR]     at org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:148)
> 15:29:42,059 ERROR [STDERR]     at org.jboss.cache.factories.ComponentRegistry$PrioritizedMethod.invoke(ComponentRegistry.java:970)
> 15:29:42,059 ERROR [STDERR]     at org.jboss.cache.factories.ComponentRegistry.internalStart(ComponentRegistry.java:746)
> 15:29:42,059 ERROR [STDERR]     at org.jboss.cache.factories.ComponentRegistry.start(ComponentRegistry.java:610)
> 15:29:42,059 ERROR [STDERR]     at org.jboss.cache.invocation.CacheInvocationDelegate.start(CacheInvocationDelegate.java:355)
> 15:29:42,059 ERROR [STDERR]     at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:121)
> 15:29:42,059 ERROR [STDERR]     at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:72)
> 15:29:42,059 ERROR [STDERR]     at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:67)
> 15:29:42,059 ERROR [STDERR]     at com.csscorp.presentation.spinneret.server.HRMSShadesGeneratorImpl.extractSpinneretPanel(HRMSShadesGeneratorImpl.java:114)
> 15:29:42,059 ERROR [STDERR]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 15:29:42,059 ERROR [STDERR]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 15:29:42,059 ERROR [STDERR]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 15:29:42,059 ERROR [STDERR]     at java.lang.reflect.Method.invoke(Method.java:597)
> 15:29:42,059 ERROR [STDERR]     at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:569)
> 15:29:42,059 ERROR [STDERR]     at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:208)
> 15:29:42,074 ERROR [STDERR]     at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:248)
> 15:29:42,074 ERROR [STDERR]     at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
> 15:29:42,074 ERROR [STDERR]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
> 15:29:42,074 ERROR [STDERR]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> 15:29:42,074 ERROR [STDERR]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324)
> 15:29:42,074 ERROR [STDERR]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242)
> 15:29:42,074 ERROR [STDERR]     at com.csscorp.business.filter.HRMSLoginFilter.doFilter(HRMSLoginFilter.java:55)
> 15:29:42,090 ERROR [STDERR]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274)
> 15:29:42,090 ERROR [STDERR]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242)
> 15:29:42,090 ERROR [STDERR]     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> 15:29:42,090 ERROR [STDERR]     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 15:29:42,090 ERROR [STDERR]     at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:181)
> 15:29:42,090 ERROR [STDERR]     at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285)
> 15:29:42,090 ERROR [STDERR]     at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261)
> 15:29:42,090 ERROR [STDERR]     at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:88)
> 15:29:42,106 ERROR [STDERR]     at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:100)
> 15:29:42,106 ERROR [STDERR]     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 15:29:42,106 ERROR [STDERR]     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 15:29:42,106 ERROR [STDERR]     at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 15:29:42,106 ERROR [STDERR]     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 15:29:42,106 ERROR [STDERR]     at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53)
> 15:29:42,106 ERROR [STDERR]     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
> 15:29:42,121 ERROR [STDERR]     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> 15:29:42,121 ERROR [STDERR]     at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:654)
> 15:29:42,121 ERROR [STDERR]     at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951)
> 15:29:42,121 ERROR [STDERR]     at java.lang.Thread.run(Thread.java:619)
> 15:29:42,121 ERROR [STDERR] Caused by: java.lang.reflect.InvocationTargetException
> 15:29:42,121 ERROR [STDERR]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 15:29:42,137 ERROR [STDERR]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 15:29:42,137 ERROR [STDERR]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 15:29:42,137 ERROR [STDERR]     at java.lang.reflect.Method.invoke(Method.java:597)
> 15:29:42,137 ERROR [STDERR]     at org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:144)
> 15:29:42,137 ERROR [STDERR]     ... 40 more
> 15:29:42,137 ERROR [STDERR] Caused by: java.lang.LinkageError: loader constraint violation: when resolving method "java.lang.management.ManagementFactory.getPlatformMBeanServer()Ljavax/management/MBeanServer;" the class loader (instance of org/jboss/classloader/spi/base/BaseClassLoader) of the current class, org/jboss/cache/jmx/JmxRegistrationManager, and the class loader (instance of <bootloader>) for resolved class, java/lang/management/ManagementFactory, have different Class objects for the type javax/management/MBeanServer used in the signature
> 15:29:42,137 ERROR [STDERR]     at org.jboss.cache.jmx.JmxRegistrationManager.<init>(JmxRegistrationManager.java:128)
> 15:29:42,153 ERROR [STDERR]     at org.jboss.cache.jmx.JmxRegistrationManager.<init>(JmxRegistrationManager.java:133)
> 15:29:42,153 ERROR [STDERR]     at org.jboss.cache.jmx.PlatformMBeanServerRegistration.registerToPlatformMBeanServer(PlatformMBeanServerRegistration.java:69)
> 15:29:42,153 ERROR [STDERR]     ... 45 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 04:39:23 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Thu, 7 Jul 2011 04:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1160) improve datasource
 test suite adding marshal and reparse xml after management operation
In-Reply-To: <1724668399.29840.1309439423844.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <362862397.39268.1310027963624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefano Maestri resolved AS7-1160.
----------------------------------

    Resolution: Done


https://github.com/jbossas/jboss-as/commit/8814dcdb3b66c1a2b53dfc149e51173871162159

> improve datasource test suite adding marshal and reparse xml after management operation
> ---------------------------------------------------------------------------------------
>
>                 Key: AS7-1160
>                 URL: https://issues.jboss.org/browse/AS7-1160
>             Project: Application Server 7
>          Issue Type: Task
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>             Fix For: 7.1.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 04:43:23 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Thu, 7 Jul 2011 04:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1169) add test case
 deploying mysql driver and adding a Mysql's datasource
In-Reply-To: <163501901.32097.1309522704601.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <750077.39272.1310028203802.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefano Maestri resolved AS7-1169.
----------------------------------

    Resolution: Done


https://github.com/jbossas/jboss-as/commit/ec43fa58ac55375de0eecde1e47f0d9661d124cd

> add test case deploying mysql driver and adding a Mysql's datasource
> --------------------------------------------------------------------
>
>                 Key: AS7-1169
>                 URL: https://issues.jboss.org/browse/AS7-1169
>             Project: Application Server 7
>          Issue Type: Sub-task
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>             Fix For: 7.1.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 04:43:23 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Thu, 7 Jul 2011 04:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1178) add test case for
 removing and re-adding datasource with same name
In-Reply-To: <1867620301.33457.1309772603681.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2026436341.39275.1310028203929.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefano Maestri resolved AS7-1178.
----------------------------------

    Resolution: Done


https://github.com/maeste/jboss-as/commit/3486023782b8378c067ff104d912b4a3242b1391

> add test case for removing and re-adding datasource with same name
> ------------------------------------------------------------------
>
>                 Key: AS7-1178
>                 URL: https://issues.jboss.org/browse/AS7-1178
>             Project: Application Server 7
>          Issue Type: Sub-task
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 04:43:24 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Thu, 7 Jul 2011 04:43:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1179) add test case for
 JDCB driver read-resource-description operation
In-Reply-To: <1076010829.33461.1309772843746.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1813016070.39278.1310028204001.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefano Maestri resolved AS7-1179.
----------------------------------

    Resolution: Done


https://github.com/maeste/jboss-as/commit/618bd2524dbc2e72f0df6619ceae7f9d5b374188

> add test case for JDCB driver read-resource-description operation
> -----------------------------------------------------------------
>
>                 Key: AS7-1179
>                 URL: https://issues.jboss.org/browse/AS7-1179
>             Project: Application Server 7
>          Issue Type: Sub-task
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 04:43:24 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Thu, 7 Jul 2011 04:43:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1180) add test case for
 read installed drivers list
In-Reply-To: <926858532.33466.1309772963809.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <667143085.39280.1310028204071.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefano Maestri resolved AS7-1180.
----------------------------------

    Resolution: Done


https://github.com/maeste/jboss-as/commit/1509436bc174a37fdcb0441916e9f539abc8c9ad

> add test case for read installed drivers list
> ---------------------------------------------
>
>                 Key: AS7-1180
>                 URL: https://issues.jboss.org/browse/AS7-1180
>             Project: Application Server 7
>          Issue Type: Sub-task
>            Reporter: Jeff Zhang
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 07:45:24 2011
From: jira-events at lists.jboss.org (Devinder Singh (JIRA))
Date: Thu, 7 Jul 2011 07:45:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-9405) could not find
 stateful bean - error
In-Reply-To: <42297151.1099.1308077069548.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1825026100.39514.1310039124059.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Devinder Singh commented on JBAS-9405:
--------------------------------------

can someone please take a look at this

> could not find stateful bean - error
> ------------------------------------
>
>                 Key: JBAS-9405
>                 URL: https://issues.jboss.org/browse/JBAS-9405
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB2
>         Environment: Red hat Linux 5.5
>            Reporter: Devinder Singh
>            Assignee: Alexey Loubyansky
>
> If I leave my browser idle for some time (around 3 mins), I get "Could not find stateful bean:" error.
> javax.ejb.NoSuchEJBException: Could not find stateful bean: 3j001-jr37lq-gorq3ofr-1-gorq6dxt-da
>  
> I grepped by bean id in logs and found below. Not sure but seems like bean is removed before it's attempted to read again.
> Is there any configuration I can do to avoid this error.
>  
> [root at localhost log]# grep 3j001-jr37lq-gorq3ofr-1-gorq6dxt-da *
> server.log:2011-06-10 18:56:25,652 DEBUG [org.jboss.ejb3.cache.simple.StatefulSessionFilePersistenceManager] (SFSB Passivation Thread - jboss.j2ee:ear=foliage.ear,jar=foliageEJB.jar,name=LoginSessionBean,service=EJB3) Attempting to passivate; id=3j001-jr37lq-gorq3ofr-1-gorq6dxt-da
> server.log:2011-06-10 18:56:25,660 DEBUG [org.jboss.ejb3.cache.simple.StatefulSessionFilePersistenceManager] (SFSB Passivation Thread - jboss.j2ee:ear=foliage.ear,jar=foliageEJB.jar,name=LoginSessionBean,service=EJB3) Saving session state to: /home/opt/jboss-6.0.0.Final/server/default/tmp/sessions/LoginSessionBean-gorq5pu2-d7/3j001-jr37lq-gorq3ofr-1-gorq6dxt-da.ser
> server.log:2011-06-10 18:56:27,206 DEBUG [org.jboss.ejb3.cache.simple.StatefulSessionFilePersistenceManager] (SFSB Passivation Thread - jboss.j2ee:ear=foliage.ear,jar=foliageEJB.jar,name=LoginSessionBean,service=EJB3) Passivation complete; id=3j001-jr37lq-gorq3ofr-1-gorq6dxt-da
> server.log:2011-06-10 18:57:16,744 DEBUG [org.jboss.ejb3.cache.simple.StatefulSessionFilePersistenceManager] (http-127.0.0.1-80-1) Attempting to activate; id=3j001-jr37lq-gorq3ofr-1-gorq6dxt-da
> server.log:2011-06-10 18:57:16,744 DEBUG [org.jboss.ejb3.cache.simple.StatefulSessionFilePersistenceManager] (http-127.0.0.1-80-1) Reading session state from: /home/opt/jboss-6.0.0.Final/server/default/tmp/sessions/LoginSessionBean-gorq5pu2-d7/3j001-jr37lq-gorq3ofr-1-gorq6dxt-da.ser
> server.log:2011-06-10 18:57:16,763 DEBUG [org.jboss.ejb3.cache.simple.StatefulSessionFilePersistenceManager] (http-127.0.0.1-80-1) Removing passivated state file: /home/opt/jboss-6.0.0.Final/server/default/tmp/sessions/LoginSessionBean-gorq5pu2-d7/3j001-jr37lq-gorq3ofr-1-gorq6dxt-da.ser
> server.log:2011-06-10 18:57:16,979 DEBUG [org.jboss.ejb3.cache.simple.StatefulSessionFilePersistenceManager] (http-127.0.0.1-80-1) Attempting to activate; id=3j001-jr37lq-gorq3ofr-1-gorq6dxt-da
> server.log:2011-06-10 18:57:16,985 DEBUG [org.jboss.ejb3.cache.simple.StatefulSessionFilePersistenceManager] (http-127.0.0.1-80-1) Attempting to activate; id=3j001-jr37lq-gorq3ofr-1-gorq6dxt-da
> server.log:2011-06-10 18:57:16,987 DEBUG [org.jboss.ejb3.cache.simple.StatefulSessionFilePersistenceManager] (http-127.0.0.1-80-1) Attempting to activate; id=3j001-jr37lq-gorq3ofr-1-gorq6dxt-da
> server.log:2011-06-10 18:57:16,989 DEBUG [org.jboss.ejb3.cache.simple.StatefulSessionFilePersistenceManager] (http-127.0.0.1-80-1) Attempting to activate; id=3j001-jr37lq-gorq3ofr-1-gorq6dxt-da
> server.log:2011-06-10 18:57:27,893 DEBUG [org.jboss.ejb3.cache.simple.StatefulSessionFilePersistenceManager] (http-127.0.0.1-80-1) Attempting to activate; id=3j001-jr37lq-gorq3ofr-1-gorq6dxt-da
> server.log:2011-06-10 18:57:27,894 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (http-127.0.0.1-80-1) Error Rendering View[/index.xhtml]: javax.el.ELException: /sections/leftSideBar.xhtml @14,46 rendered="#{! loginbacking.loggedIn}": javax.ejb.NoSuchEJBException: Could not find stateful bean: 3j001-jr37lq-gorq3ofr-1-gorq6dxt-da
> server.log:Caused by: javax.ejb.NoSuchEJBException: Could not find stateful bean: 3j001-jr37lq-gorq3ofr-1-gorq6dxt-da
> server.log:2011-06-10 18:57:27,998 DEBUG [org.jboss.ejb3.cache.simple.StatefulSessionFilePersistenceManager] (http-127.0.0.1-80-1) Attempting to activate; id=3j001-jr37lq-gorq3ofr-1-gorq6dxt-da

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 08:09:23 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Thu, 7 Jul 2011 08:09:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1206) test for jndi
 binding isn't unbound during remove if jndi name and data-source name are
 different
In-Reply-To: <915284666.37316.1309955363700.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <358922009.39569.1310040563824.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefano Maestri reassigned AS7-1206:
------------------------------------

    Assignee: Stefano Maestri


> test for jndi binding isn't unbound during remove if jndi name and data-source name are different
> -------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1206
>                 URL: https://issues.jboss.org/browse/AS7-1206
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: Test Suite
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>             Fix For: 7.1.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 08:35:23 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Thu, 7 Jul 2011 08:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1201) test for en/diable
	xa datasources
In-Reply-To: <628827184.37288.1309954883712.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <754685415.39670.1310042123871.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefano Maestri reassigned AS7-1201:
------------------------------------

    Assignee: Stefano Maestri


> test for en/diable xa datasources
> ---------------------------------
>
>                 Key: AS7-1201
>                 URL: https://issues.jboss.org/browse/AS7-1201
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: Test Suite
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>             Fix For: 7.1.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 08:43:23 2011
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Thu, 7 Jul 2011 08:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBLOGGING-68) Include
 LICENSE.txt in META-INF directories of binaries
Message-ID: <432278637.39708.1310042603715.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Include LICENSE.txt in META-INF directories of binaries
-------------------------------------------------------

                 Key: JBLOGGING-68
                 URL: https://issues.jboss.org/browse/JBLOGGING-68
             Project: JBoss Logging
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 3.0.0.Beta5-jboss-logging
            Reporter: Pete Muir
            Assignee: David Lloyd
            Priority: Minor


This helps users when analysing the licensing requirements for clearance to use a library.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 08:47:23 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Thu, 7 Jul 2011 08:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1200) test case for xa
 datasource persistence to xml
In-Reply-To: <688662445.37283.1309954644343.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <531100023.39730.1310042843730.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefano Maestri reassigned AS7-1200:
------------------------------------

    Assignee: Stefano Maestri


> test case for xa datasource persistence to xml
> ----------------------------------------------
>
>                 Key: AS7-1200
>                 URL: https://issues.jboss.org/browse/AS7-1200
>             Project: Application Server 7
>          Issue Type: Sub-task
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>             Fix For: 7.1.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 09:21:23 2011
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Thu, 7 Jul 2011 09:21:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (JBEE-86) Add LICENSE.txt to
	binary's META-INF
Message-ID: <618988141.39815.1310044883806.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Pete Muir moved JBTM-857 to JBEE-86:
------------------------------------

     Project: JBoss JavaEE APIs  (was: JBoss Transaction Manager)
         Key: JBEE-86  (was: JBTM-857)
    Security:     (was: Public)


> Add LICENSE.txt to binary's META-INF
> ------------------------------------
>
>                 Key: JBEE-86
>                 URL: https://issues.jboss.org/browse/JBEE-86
>             Project: JBoss JavaEE APIs
>          Issue Type: Task
>         Environment: jboss-transaction-api-1.0.1.GA.jar
>            Reporter: Pete Muir
>
> The jboss-transaction-api-1.0.1.GA.jar is missing this file, which is useful as it means a user can easily verify the licensing requirements for dependencies

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 10:34:23 2011
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Thu, 7 Jul 2011 10:34:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-493) Integrate
	hornetq-ra.rar into AS 7
In-Reply-To: <1342826652.46712.1300887893374.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <582639549.40042.1310049263870.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jason Greene closed AS7-493.
----------------------------

    Fix Version/s: 7.0.0.CR1
                       (was: 7.1.0.Alpha1)
       Resolution: Done


> Integrate hornetq-ra.rar into AS 7
> ----------------------------------
>
>                 Key: AS7-493
>                 URL: https://issues.jboss.org/browse/AS7-493
>             Project: Application Server 7
>          Issue Type: Task
>          Components: JMS
>            Reporter: Carlo de Wolf
>            Assignee: Andy Taylor
>             Fix For: 7.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 11:00:26 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 7 Jul 2011 11:00:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-625) IronJacamar
	1.0.0.Final
Message-ID: <235306452.40092.1310050826106.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

IronJacamar 1.0.0.Final
-----------------------

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


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

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 11:02:24 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 7 Jul 2011 11:02:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-625) IronJacamar
	1.0.0.Final
In-Reply-To: <235306452.40092.1310050826106.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <142375639.40103.1310050944166.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen resolved JBJCA-625.
-----------------------------------

    Resolution: Done


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

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 11:04:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 7 Jul 2011 11:04:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-616) JBoss Stdio 1.0.0.GA
In-Reply-To: <294598216.37788.1309968803651.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1527181577.40107.1310051063897.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen resolved JBJCA-616.
-----------------------------------

    Resolution: Done


> JBoss Stdio 1.0.0.GA
> --------------------
>
>                 Key: JBJCA-616
>                 URL: https://issues.jboss.org/browse/JBJCA-616
>             Project: IronJacamar
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 11:04:24 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 7 Jul 2011 11:04:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-618) SLF4J 1.6.1
In-Reply-To: <1891272773.37794.1309968923834.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1923634481.40110.1310051064013.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen resolved JBJCA-618.
-----------------------------------

    Resolution: Done


> SLF4J 1.6.1
> -----------
>
>                 Key: JBJCA-618
>                 URL: https://issues.jboss.org/browse/JBJCA-618
>             Project: IronJacamar
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 11:04:24 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 7 Jul 2011 11:04:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-613) JBoss Logging
	3.0.0.GA
In-Reply-To: <1403401756.37779.1309968683789.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1938403021.40113.1310051064137.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen resolved JBJCA-613.
-----------------------------------

    Resolution: Done


> JBoss Logging 3.0.0.GA
> ----------------------
>
>                 Key: JBJCA-613
>                 URL: https://issues.jboss.org/browse/JBJCA-613
>             Project: IronJacamar
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 11:04:24 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 7 Jul 2011 11:04:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-614) PicketBox
	4.0.0.Final
In-Reply-To: <830823337.37781.1309968683840.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <151156845.40116.1310051064241.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen resolved JBJCA-614.
-----------------------------------

    Resolution: Done


> PicketBox 4.0.0.Final
> ---------------------
>
>                 Key: JBJCA-614
>                 URL: https://issues.jboss.org/browse/JBJCA-614
>             Project: IronJacamar
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 11:04:24 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 7 Jul 2011 11:04:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-617) JBoss Threads
	2.0.0.GA
In-Reply-To: <662627998.37791.1309968803753.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1584160721.40119.1310051064352.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen resolved JBJCA-617.
-----------------------------------

    Resolution: Done


> JBoss Threads 2.0.0.GA
> ----------------------
>
>                 Key: JBJCA-617
>                 URL: https://issues.jboss.org/browse/JBJCA-617
>             Project: IronJacamar
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 11:04:24 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 7 Jul 2011 11:04:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-612) Track component
	updates
In-Reply-To: <2087031214.37776.1309968683690.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <250159306.40122.1310051064465.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen resolved JBJCA-612.
-----------------------------------

    Resolution: Done


> Track component updates
> -----------------------
>
>                 Key: JBJCA-612
>                 URL: https://issues.jboss.org/browse/JBJCA-612
>             Project: IronJacamar
>          Issue Type: Task
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 11:04:24 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 7 Jul 2011 11:04:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-615) SLF4J LogManager
	1.0.0.GA
In-Reply-To: <1880663443.37783.1309968683900.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <724460337.40123.1310051064520.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen resolved JBJCA-615.
-----------------------------------

    Resolution: Done


> SLF4J LogManager 1.0.0.GA
> -------------------------
>
>                 Key: JBJCA-615
>                 URL: https://issues.jboss.org/browse/JBJCA-615
>             Project: IronJacamar
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.0.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 11:31:23 2011
From: jira-events at lists.jboss.org (Tom Fonteyne (JIRA))
Date: Thu, 7 Jul 2011 11:31:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCL-179) backport the removal
 of the use of toLongString() from the line: throw new
 ClassNotFoundException(name + " from " + toLongString()); 
Message-ID: <151376159.40171.1310052683800.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

backport the removal of the use of  toLongString() from the line:  throw new ClassNotFoundException(name + " from " + toLongString());
--------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBCL-179
                 URL: https://issues.jboss.org/browse/JBCL-179
             Project: JBoss ClassLoader
          Issue Type: Bug
          Components: ClassLoader
    Affects Versions:  JBossCL.2.0.7.GA
         Environment: all
            Reporter: Tom Fonteyne
            Assignee: Ales Justin
            Priority: Minor
             Fix For:  JBossCL.2.0.7.GA


When a class is not found, the classloader code throws:
   ClassNotFoundException(name + " from " + toLongString());

The toLongString uses a lot of memory each time it's called.
In 2.0.9 the line is using:
   ClassNotFoundException(name + " from " + toString());

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 11:44:23 2011
From: jira-events at lists.jboss.org (Scott Embler (JIRA))
Date: Thu, 7 Jul 2011 11:44:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3121) Enriching Jar
 Model with event annotations causes RuntimeDroolsException in guvnor
Message-ID: <408376864.40207.1310053463663.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Enriching Jar Model with event annotations causes RuntimeDroolsException in guvnor
----------------------------------------------------------------------------------

                 Key: JBRULES-3121
                 URL: https://issues.jboss.org/browse/JBRULES-3121
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-guvnor
    Affects Versions: 5.2.0.Final
         Environment: Windows XP
JDK 1.6.0_26
Tomcat 6.0
Guvnor 5.2.0.Final
Drools-core 5.2.0.Final + dependencies
            Reporter: Scott Embler
            Assignee: Mark Proctor


Attempting to validate a declared model (or build a package using such a model) that annotates an existing class as an event causes this:

ERROR 07-07 10:45:42,789 (LoggingHelper.java:error:69)   Unable to build asset.
org.drools.RuntimeDroolsException: Field/method 'timestamp' not found for class 'org.drools.test.even.MyEvent'

        at org.drools.base.ClassFieldAccessorFactory.getClassFieldReader(ClassFieldAccessorFactory.java:136)
        at org.drools.base.ClassFieldAccessorCache$CacheEntry.getReadAccessor(ClassFieldAccessorCache.java:169)
        at org.drools.base.ClassFieldAccessorCache.getReadAcessor(ClassFieldAccessorCache.java:102)
        at org.drools.base.ClassFieldAccessorStore.wire(ClassFieldAccessorStore.java:419)
        at org.drools.base.ClassFieldAccessorStore.getReader(ClassFieldAccessorStore.java:118)
        at org.drools.base.ClassFieldAccessorStore.getReader(ClassFieldAccessorStore.java:95)
        at org.drools.compiler.PackageBuilder.processTypeDeclarations(PackageBuilder.java:1553)
        at org.drools.compiler.PackageBuilder.mergePackage(PackageBuilder.java:985)
        at org.drools.compiler.PackageBuilder.newPackage(PackageBuilder.java:973)
        at org.drools.compiler.PackageBuilder.processTypeDeclarations(PackageBuilder.java:1439)
        at org.drools.compiler.PackageBuilder.mergePackage(PackageBuilder.java:985)
        at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:689)
        at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:338)
        at org.drools.guvnor.server.builder.PackageAssemblerBase.addDrl(PackageAssemblerBase.java:216)
        at org.drools.guvnor.server.builder.PackageAssemblerBase.loadDeclaredTypes(PackageAssemblerBase.java:183)
        at org.drools.guvnor.server.builder.PackageAssemblerBase.setUpPackage(PackageAssemblerBase.java:87)
        at org.drools.guvnor.server.builder.AssetItemValidator$BuilderValidator.validate(AssetItemValidator.java:53)
        at org.drools.guvnor.server.builder.AssetItemValidator.validate(AssetItemValidator.java:42)
        at org.drools.guvnor.server.RepositoryAssetOperations.validateAsset(RepositoryAssetOperations.java:86)
        at org.drools.guvnor.server.RepositoryAssetService.validateAsset(RepositoryAssetService.java:392)
        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.seam.util.Reflections.invoke(Reflections.java:22)
        at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:56)
        at org.jboss.seam.transaction.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:28)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
        at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:77)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
        at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
        at org.jboss.seam.security.SecurityInterceptor.aroundInvoke(SecurityInterceptor.java:157)
        at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
        at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
        at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:166)
        at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:102)
        at org.drools.guvnor.server.RepositoryAssetService_$$_javassist_5.validateAsset(RepositoryAssetService_$$_javassist_
5.java)
        at org.drools.guvnor.server.RepositoryServiceServlet.validateAsset(RepositoryServiceServlet.java:427)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:569)
        at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:208)
        at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:248)
        at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.jboss.seam.web.ContextFilter$1.process(ContextFilter.java:42)
        at org.jboss.seam.servlet.ContextualHttpServletRequest.run(ContextualHttpServletRequest.java:53)
        at org.jboss.seam.web.ContextFilter.doFilter(ContextFilter.java:37)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        at java.lang.Thread.run(Thread.java:662)

A curious thing to note is that the class this exception describes is a misspelling of the uploaded class ('org.drools.test.even.MyEvent' instead of 'org.drools.test.event.MyEvent')

Another thing worth noting is that if the timestamp field is removed from the declaration, everything will validate.  But, when the package is used to create a knowledgebase, objects of the class that was declared to be an event do not activate any rules.  However, if the event declaration is removed completely, the rules will fire (but of course the facts will no longer be treated as events).  Could the misspelling be causing this behavior?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 12:00:24 2011
From: jira-events at lists.jboss.org (Daniel Marchese (JIRA))
Date: Thu, 7 Jul 2011 12:00:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1218) Ability to specify a
 delay between URL round-robin attempts in HA datasource
Message-ID: <129647420.40238.1310054424206.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Ability to specify a delay between URL round-robin attempts in HA datasource
----------------------------------------------------------------------------

                 Key: AS7-1218
                 URL: https://issues.jboss.org/browse/AS7-1218
             Project: Application Server 7
          Issue Type: Feature Request
          Components: JCA
    Affects Versions: 7.0.0.CR1
            Reporter: Daniel Marchese


We have a configuration with Oracle RAC One Node (1 active database, 1 standby database) and we are testing HA possibilities.
In one test, if we try to obtain a connection during the starting of the standby database after the active database crash, we get an ORA-12514 error because the standby instance is not ready to respond.
Besides the fact that Oracle should not return an error but wait for the standby database to be ready to respond, it would be interesting if it was possible to specify a delay between URL round-roubin attempts in the HA datasource (ex: url-retry-wait-millis).
This way, it would be possible to ask JBoss to wait before it tries the next URL in the list, giving the standby database the time to start.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 12:00:24 2011
From: jira-events at lists.jboss.org (Brad Maxwell (JIRA))
Date: Thu, 7 Jul 2011 12:00:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCL-179) backport the removal
 of the use of toLongString() from the line: throw new
 ClassNotFoundException(name + " from " + toLongString()); 
In-Reply-To: <151376159.40171.1310052683800.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <482283299.40242.1310054424716.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brad Maxwell reassigned JBCL-179:
---------------------------------

    Assignee: Brad Maxwell  (was: Ales Justin)


> backport the removal of the use of  toLongString() from the line:  throw new ClassNotFoundException(name + " from " + toLongString());
> --------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCL-179
>                 URL: https://issues.jboss.org/browse/JBCL-179
>             Project: JBoss ClassLoader
>          Issue Type: Bug
>          Components: ClassLoader
>    Affects Versions:  JBossCL.2.0.7.GA
>         Environment: all
>            Reporter: Tom Fonteyne
>            Assignee: Brad Maxwell
>            Priority: Minor
>              Labels: memory
>             Fix For:  JBossCL.2.0.7.GA
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> When a class is not found, the classloader code throws:
>    ClassNotFoundException(name + " from " + toLongString());
> The toLongString uses a lot of memory each time it's called.
> In 2.0.9 the line is using:
>    ClassNotFoundException(name + " from " + toString());

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 12:20:23 2011
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Thu, 7 Jul 2011 12:20:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBEE-86) Add LICENSE.txt to
 binary's META-INF
Message-ID: <725810255.40301.1310055623632.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Shelly McGowan commented on JBEE-86:
------------------------------------

I'll make the necessary adjustment to the build to be sure the license files are included.  Note, the version being used in most projects is:
jboss-transaction-api_1.1_spec-1.0.0.Final.jar.


jboss-transactino-api_1.1_spec-1.0.1-Beta1.jar was released specifically for the Infinispan team (JBEE-67).
This request prompted a wider discussion of whether all API releases should be OSGi bundles.   In the informal discussions I've participated in, sounded like a good idea.  


> Add LICENSE.txt to binary's META-INF
> ------------------------------------
>
>                 Key: JBEE-86
>                 URL: https://issues.jboss.org/browse/JBEE-86
>             Project: JBoss JavaEE APIs
>          Issue Type: Task
>         Environment: jboss-transaction-api-1.0.1.GA.jar
>            Reporter: Pete Muir
>
> The jboss-transaction-api-1.0.1.GA.jar is missing this file, which is useful as it means a user can easily verify the licensing requirements for dependencies

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 12:28:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 7 Jul 2011 12:28:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1219) Add jboss-dmr
 documentation to the Admin Guide
Message-ID: <896759888.40346.1310056103706.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Add jboss-dmr documentation to the Admin Guide
----------------------------------------------

                 Key: AS7-1219
                 URL: https://issues.jboss.org/browse/AS7-1219
             Project: Application Server 7
          Issue Type: Task
          Components: Domain Management
            Reporter: Brian Stansberry


Basic documentation on DMR:

1) Purpose
2) Source location and maven coordinates
3) Description of the 2 public classes, ModelNode and ModelType, link to 1.0.0.Final code for each on github
4) Some simple examples
5) Fully document the string format, so people know how to read DMR output and how to write DMR input
6) Links to 5) above in the CLI docs, both in a place that describes how to read output and in a place that describes the format for parameter values in low-level operation requests 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 12:34:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 7 Jul 2011 12:34:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1220) Add native management
 (ModelControllerClient) API docs to the Admin Guide
Message-ID: <1106331286.40360.1310056463696.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Add native management  (ModelControllerClient) API docs to the Admin Guide
--------------------------------------------------------------------------

                 Key: AS7-1220
                 URL: https://issues.jboss.org/browse/AS7-1220
             Project: Application Server 7
          Issue Type: Task
          Components: Domain Management
            Reporter: Brian Stansberry


There's some brief docs on configuring the native management interface. There is a separate JIRA for some fundamental docs on jboss-dmr. There will be a page in the "Core management concepts" section on what management resources, attributes and operations are.

This task is to reference those elements and bring together a coherent picture of how to use the ModelControllerClient API.

A subtask would be to add docs on the helper classes in controller-client, although I'm fine with deferring that bit until later in the AS 7.1 cycle,

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 12:45:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 7 Jul 2011 12:45:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1221) HTTP management API
 section in the Admin Guide
Message-ID: <603099484.40379.1310057124161.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

HTTP management API section in the Admin Guide
----------------------------------------------

                 Key: AS7-1221
                 URL: https://issues.jboss.org/browse/AS7-1221
             Project: Application Server 7
          Issue Type: Task
          Components: Domain Management
            Reporter: Brian Stansberry


We need a technical guide to the HTTP management API.

The "Management clients" section gives a basic overview. But it should reference a separate section that documents the usage of GET and POST, the URL patterns, the JSON representation of DMR etc.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 12:47:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 7 Jul 2011 12:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1221) HTTP management API
 section in the Admin Guide
In-Reply-To: <603099484.40379.1310057124161.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1303527008.40383.1310057243816.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-1221:
----------------------------------

    Fix Version/s: 7.0.0.Final


> HTTP management API section in the Admin Guide
> ----------------------------------------------
>
>                 Key: AS7-1221
>                 URL: https://issues.jboss.org/browse/AS7-1221
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 7.0.0.Final
>
>
> We need a technical guide to the HTTP management API.
> The "Management clients" section gives a basic overview. But it should reference a separate section that documents the usage of GET and POST, the URL patterns, the JSON representation of DMR etc.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 12:49:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 7 Jul 2011 12:49:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1220) Add native management
 (ModelControllerClient) API docs to the Admin Guide
In-Reply-To: <1106331286.40360.1310056463696.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <73125151.40387.1310057363662.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-1220:
----------------------------------

    Fix Version/s: 7.0.0.Final


> Add native management  (ModelControllerClient) API docs to the Admin Guide
> --------------------------------------------------------------------------
>
>                 Key: AS7-1220
>                 URL: https://issues.jboss.org/browse/AS7-1220
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 7.0.0.Final
>
>
> There's some brief docs on configuring the native management interface. There is a separate JIRA for some fundamental docs on jboss-dmr. There will be a page in the "Core management concepts" section on what management resources, attributes and operations are.
> This task is to reference those elements and bring together a coherent picture of how to use the ModelControllerClient API.
> A subtask would be to add docs on the helper classes in controller-client, although I'm fine with deferring that bit until later in the AS 7.1 cycle,

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 12:49:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 7 Jul 2011 12:49:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1219) Add jboss-dmr
 documentation to the Admin Guide
In-Reply-To: <896759888.40346.1310056103706.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1912797687.40389.1310057363729.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-1219:
----------------------------------

    Fix Version/s: 7.0.0.Final


> Add jboss-dmr documentation to the Admin Guide
> ----------------------------------------------
>
>                 Key: AS7-1219
>                 URL: https://issues.jboss.org/browse/AS7-1219
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 7.0.0.Final
>
>
> Basic documentation on DMR:
> 1) Purpose
> 2) Source location and maven coordinates
> 3) Description of the 2 public classes, ModelNode and ModelType, link to 1.0.0.Final code for each on github
> 4) Some simple examples
> 5) Fully document the string format, so people know how to read DMR output and how to write DMR input
> 6) Links to 5) above in the CLI docs, both in a place that describes how to read output and in a place that describes the format for parameter values in low-level operation requests 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 12:53:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 7 Jul 2011 12:53:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1222) Subsystem developers
	guide
Message-ID: <1987751614.40396.1310057603656.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Subsystem developers guide
--------------------------

                 Key: AS7-1222
                 URL: https://issues.jboss.org/browse/AS7-1222
             Project: Application Server 7
          Issue Type: Task
            Reporter: Brian Stansberry
            Assignee: Kabir Khan
             Fix For: 7.0.1.Final


A guide on how to develop an AS7 extension/subsystem and a maven archetype for same.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 12:55:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 7 Jul 2011 12:55:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1223) Document the global
 operations in the Admin Guide
Message-ID: <1714268649.40407.1310057724010.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Document the global operations in the Admin Guide
-------------------------------------------------

                 Key: AS7-1223
                 URL: https://issues.jboss.org/browse/AS7-1223
             Project: Application Server 7
          Issue Type: Task
          Components: Domain Management
            Reporter: Brian Stansberry
             Fix For: 7.0.0.Final


Document the global operations.

Should cover "add" and "remove" as well.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 12:57:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 7 Jul 2011 12:57:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1224) Document the
 "management resource" notion in the Admin Guide
Message-ID: <356943798.40411.1310057843613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Document the "management resource" notion in the Admin Guide
------------------------------------------------------------

                 Key: AS7-1224
                 URL: https://issues.jboss.org/browse/AS7-1224
             Project: Application Server 7
          Issue Type: Task
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 7.0.0.Final


In the "Core management concepts" section of the Admin Guide, add a section describing what a management resource is and outlining the basic resource tree server for both a standalone server and a managed domain.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 12:59:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 7 Jul 2011 12:59:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1220) Add native
 management (ModelControllerClient) API docs to the Admin Guide
In-Reply-To: <1106331286.40360.1310056463696.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1622717485.40415.1310057963697.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on AS7-1220:
---------------------------------------

See http://community.jboss.org/docs/DOC-16336 and http://community.jboss.org/docs/DOC-16354 for a lot of content that can be brought in.

> Add native management  (ModelControllerClient) API docs to the Admin Guide
> --------------------------------------------------------------------------
>
>                 Key: AS7-1220
>                 URL: https://issues.jboss.org/browse/AS7-1220
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 7.0.0.Final
>
>
> There's some brief docs on configuring the native management interface. There is a separate JIRA for some fundamental docs on jboss-dmr. There will be a page in the "Core management concepts" section on what management resources, attributes and operations are.
> This task is to reference those elements and bring together a coherent picture of how to use the ModelControllerClient API.
> A subtask would be to add docs on the helper classes in controller-client, although I'm fine with deferring that bit until later in the AS 7.1 cycle,

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 13:59:23 2011
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 7 Jul 2011 13:59:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBEE-86) Add LICENSE.txt to
 binary's META-INF
Message-ID: <1769995328.40512.1310061563671.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Gier commented on JBEE-86:
-------------------------------

For a temporary fix we can just add the LICENSE.txt file to each project's src/main/resources/META-INF dir, then Maven will add it to the jar.  Longer term maybe we want to use the remote-resources plugin to do this similar to how it works in upstream Maven.

> Add LICENSE.txt to binary's META-INF
> ------------------------------------
>
>                 Key: JBEE-86
>                 URL: https://issues.jboss.org/browse/JBEE-86
>             Project: JBoss JavaEE APIs
>          Issue Type: Task
>         Environment: jboss-transaction-api-1.0.1.GA.jar
>            Reporter: Pete Muir
>
> The jboss-transaction-api-1.0.1.GA.jar is missing this file, which is useful as it means a user can easily verify the licensing requirements for dependencies

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 14:43:23 2011
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Thu, 7 Jul 2011 14:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBEE-86) Add LICENSE.txt to
 binary's META-INF
Message-ID: <908785442.40534.1310064203709.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Pete Muir commented on JBEE-86:
-------------------------------

FYI I blogged about how we do this in Infinispan and Weld :-)

I also add a DEPENDENCIES.txt report to every jar, with the license of all deps.

> Add LICENSE.txt to binary's META-INF
> ------------------------------------
>
>                 Key: JBEE-86
>                 URL: https://issues.jboss.org/browse/JBEE-86
>             Project: JBoss JavaEE APIs
>          Issue Type: Task
>         Environment: jboss-transaction-api-1.0.1.GA.jar
>            Reporter: Pete Muir
>
> The jboss-transaction-api-1.0.1.GA.jar is missing this file, which is useful as it means a user can easily verify the licensing requirements for dependencies

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 14:47:23 2011
From: jira-events at lists.jboss.org (Pete Muir (JIRA))
Date: Thu, 7 Jul 2011 14:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (JBEE-86) Add
 LICENSE.txt to binary's META-INF
Message-ID: <2010364242.40540.1310064443674.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Pete Muir edited comment on JBEE-86 at 7/7/11 2:46 PM:
-------------------------------------------------------

FYI I blogged about how we do this in Infinispan and Weld :-) http://in.relation.to/Bloggers/HowToAddADependenciesReportToYourJarWithMaven

I also add a DEPENDENCIES.txt report to every jar, with the license of all deps.

      was (Author: petemuir):
    FYI I blogged about how we do this in Infinispan and Weld :-)

I also add a DEPENDENCIES.txt report to every jar, with the license of all deps.
  
> Add LICENSE.txt to binary's META-INF
> ------------------------------------
>
>                 Key: JBEE-86
>                 URL: https://issues.jboss.org/browse/JBEE-86
>             Project: JBoss JavaEE APIs
>          Issue Type: Task
>         Environment: jboss-transaction-api-1.0.1.GA.jar
>            Reporter: Pete Muir
>
> The jboss-transaction-api-1.0.1.GA.jar is missing this file, which is useful as it means a user can easily verify the licensing requirements for dependencies

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 15:20:23 2011
From: jira-events at lists.jboss.org (Daniel Marchese (JIRA))
Date: Thu, 7 Jul 2011 15:20:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1218) Ability to specify
 a delay between URL round-robin attempts in HA datasource
In-Reply-To: <129647420.40238.1310054424206.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <993849347.40564.1310066423636.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Daniel Marchese commented on AS7-1218:
--------------------------------------

I was hoping that I could obtain a good result using the existing <allocation-retry> and <allocation-retry-wait-millis> with a single URL pointing to the RAC instance but it is not working as expected because these 2 properties are not replicated to the TxConnectionManager instance.
I have tried to set the properties manually in debug mode and it works.
Here is my datasource configuration :
{code:java} 
    <local-tx-datasource>
        <jndi-name>jdbc/ds</jndi-name>
        <rar-name>jboss-local-jdbc.rar</rar-name>
        <use-java-context>false</use-java-context>
        <connection-definition>javax.sql.DataSource</connection-definition>
        <jmx-invoker-name>jboss:service=invoker,type=jrmp</jmx-invoker-name>
        <min-pool-size>0</min-pool-size>
        <max-pool-size>10</max-pool-size>
        <blocking-timeout-millis>30000</blocking-timeout-millis>
        <idle-timeout-minutes>30</idle-timeout-minutes>
        <prefill>false</prefill>
        <background-validation>false</background-validation>
        <background-validation-millis>0</background-validation-millis>
        <validate-on-match>true</validate-on-match>
        <statistics-formatter>org.jboss.resource.statistic.pool.JBossDefaultSubPoolStatisticFormatter</statistics-formatter>
        <isSameRM-override-value>false</isSameRM-override-value>
        <allocation-retry>2</allocation-retry>
        <allocation-retry-wait-millis>10000</allocation-retry-wait-millis>
        <application-managed-security xsi:type="securityMetaData" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
        <metadata>
            <type-mapping>Oracle9i</type-mapping>
        </metadata>
        <type-mapping>Oracle9i</type-mapping>
        <local-transaction/>
        <user-name>XXXX</user-name>
        <password>XXXX</password>
        <check-valid-connection-sql>SELECT * FROM DUAL</check-valid-connection-sql>
        <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
        <prepared-statement-cache-size>0</prepared-statement-cache-size>
        <share-prepared-statements>false</share-prepared-statements>
        <set-tx-query-timeout>false</set-tx-query-timeout>
        <query-timeout>0</query-timeout>
        <use-try-lock>60000</use-try-lock>
        <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
        <connection-url>jdbc:oracle:oci:@(DESCRIPTION=(ENABLE=BROKEN)(LOAD_BALANCE=off)(FAILOVER=on)(ADDRESS=(PROTOCOL=tcp)(HOST=cluster-scan)(PORT=1528))(CONNECT_DATA=(SERVICE_NAME=RAC_INSTANCE)(FAILOVER_MODE=(TYPE=select)(METHOD=basic)(RETRIES=180)(DELAY=1))))</connection-url>
    </local-tx-datasource>
{code}

> Ability to specify a delay between URL round-robin attempts in HA datasource
> ----------------------------------------------------------------------------
>
>                 Key: AS7-1218
>                 URL: https://issues.jboss.org/browse/AS7-1218
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: JCA
>    Affects Versions: 7.0.0.CR1
>            Reporter: Daniel Marchese
>
> We have a configuration with Oracle RAC One Node (1 active database, 1 standby database) and we are testing HA possibilities.
> In one test, if we try to obtain a connection during the starting of the standby database after the active database crash, we get an ORA-12514 error because the standby instance is not ready to respond.
> Besides the fact that Oracle should not return an error but wait for the standby database to be ready to respond, it would be interesting if it was possible to specify a delay between URL round-roubin attempts in the HA datasource (ex: url-retry-wait-millis).
> This way, it would be possible to ask JBoss to wait before it tries the next URL in the list, giving the standby database the time to start.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 16:02:23 2011
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 7 Jul 2011 16:02:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1163) The license of JBoss
 AS itself is not evident in the distribution
In-Reply-To: <1211201247.31687.1309509204437.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1237002034.40589.1310068943641.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Gier resolved AS7-1163.
----------------------------

      Assignee: Jason Greene  (was: Paul Gier)
    Resolution: Done


Looks like Jason took care of this.
https://github.com/jbossas/jboss-as/commit/3a17f304e5aaf3cecdd16d485f34d85cdc0b3380

> The license of JBoss AS itself is not evident in the distribution
> -----------------------------------------------------------------
>
>                 Key: AS7-1163
>                 URL: https://issues.jboss.org/browse/AS7-1163
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Build System
>    Affects Versions: 7.0.0.CR1
>            Reporter: Dimitris Andreadis
>            Assignee: Jason Greene
>            Priority: Critical
>             Fix For: 7.0.0.Final
>
>
> When looking in the distribution, it's not evident what is the license of the application server itself.
> We have the licenses for the various subsystems in docs/licenses and the docs/licenses/licenses.xml containing entries like
>     <dependency>
>       <groupId>org.jboss.as</groupId>
>       <artifactId>jboss-as-build-config</artifactId>
>       <version>7.0.0.CR1</version>
>       <licenses>
>         <license>
>           <name>lgpl</name>
>           <url>http://repository.jboss.org/licenses/lgpl-2.1.txt</url>
>         </license>
>       </licenses>
>     </dependency>
> But I think we need something more explicit like we had in previous releases.
> Maybe a txt file LICENSE.txt either in docs/licenses, or in the top level directory.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 16:44:23 2011
From: jira-events at lists.jboss.org (Scott Stark (JIRA))
Date: Thu, 7 Jul 2011 16:44:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1225) jboss-admin.sh fails
 to exit when run in single command mode
Message-ID: <627196052.40655.1310071463653.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

jboss-admin.sh fails to exit when run in single command mode
------------------------------------------------------------

                 Key: AS7-1225
                 URL: https://issues.jboss.org/browse/AS7-1225
             Project: Application Server 7
          Issue Type: Bug
          Components: CLI
    Affects Versions: 7.0.0.CR1
            Reporter: Scott Stark


This seems to be a new behavior, but regardless it is a problem that breaks other frameworks that call out to the command line shell with a single command and expect it to return. Currently it fails to exit, and callers hang. This is true both in the case of the server running with a management interface, and when one is missing:

[269](ironmaiden:bin) > ./jboss-admin.sh --connect command=:shutdown
Connected to standalone controller at localhost:9999
Communication error: Channel closed
Closed connection to localhost:9999
^C

[270](ironmaiden:bin) > ./jboss-admin.sh --connect command=:shutdown
The controller is not available at localhost:9999
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
^C

When running a mode where the commands to run are from a file or command line, that is, non-interactive mode, the cli should exit with a status.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 17:17:23 2011
From: jira-events at lists.jboss.org (Scott Stark (JIRA))
Date: Thu, 7 Jul 2011 17:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1225) jboss-admin.sh
 fails to exit when run in single command mode
In-Reply-To: <627196052.40655.1310071463653.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <38597869.40699.1310073443690.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Stark commented on AS7-1225:
----------------------------------

I see the code is just returning from main when in non-interactive mode, but there are non-daemon threads keeping the process from exiting:

[271](ironmaiden:bin) > ./jboss-admin.sh --connect command=:shutdown
The controller is not available at localhost:9999
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
^\2011-07-07 14:13:36
Full thread dump Java HotSpot(TM) 64-Bit Server VM (19.1-b02-334 mixed mode):

"DestroyJavaVM" prio=5 tid=101801000 nid=0x100601000 waiting on condition [00000000]
   java.lang.Thread.State: RUNNABLE

"pool-1-thread-3" prio=5 tid=102940000 nid=0x10c50a000 waiting on condition [10c509000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <7f42c8aa0> (a java.util.concurrent.SynchronousQueue$TransferStack)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198)
	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:424)
	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:323)
	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:874)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:945)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
	at java.lang.Thread.run(Thread.java:680)

"pool-1-thread-2" prio=5 tid=101a06000 nid=0x10c793000 waiting on condition [10c792000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <7f42c8aa0> (a java.util.concurrent.SynchronousQueue$TransferStack)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198)
	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:424)
	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:323)
	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:874)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:945)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
	at java.lang.Thread.run(Thread.java:680)

"pool-1-thread-1" prio=5 tid=10bb09000 nid=0x10c407000 waiting on condition [10c406000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <7f42c8aa0> (a java.util.concurrent.SynchronousQueue$TransferStack)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198)
	at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:424)
	at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:323)
	at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:874)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:945)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
	at java.lang.Thread.run(Thread.java:680)

"Poller SunPKCS11-Darwin" daemon prio=1 tid=101964000 nid=0x10c304000 waiting on condition [10c303000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
	at java.lang.Thread.sleep(Native Method)
	at sun.security.pkcs11.SunPKCS11$TokenPoller.run(SunPKCS11.java:692)
	at java.lang.Thread.run(Thread.java:680)

"Reference Reaper" daemon prio=5 tid=101a07000 nid=0x10c201000 in Object.wait() [10c200000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <7f42b4070> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
	- locked <7f42b4070> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
	at org.jboss.modules.ref.References$ReaperThread.run(References.java:68)

"Low Memory Detector" daemon prio=5 tid=10280c000 nid=0x10b201000 runnable [00000000]
   java.lang.Thread.State: RUNNABLE

"CompilerThread1" daemon prio=9 tid=10280b000 nid=0x10a70a000 waiting on condition [00000000]
   java.lang.Thread.State: RUNNABLE

"CompilerThread0" daemon prio=9 tid=10280a800 nid=0x10a607000 waiting on condition [00000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=9 tid=102809800 nid=0x10a504000 waiting on condition [00000000]
   java.lang.Thread.State: RUNNABLE

"Surrogate Locker Thread (CMS)" daemon prio=5 tid=102809000 nid=0x10a401000 waiting on condition [00000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=8 tid=1018d2000 nid=0x109eea000 in Object.wait() [109ee9000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <7f42b4260> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
	- locked <7f42b4260> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

"Reference Handler" daemon prio=10 tid=1018d1000 nid=0x109de7000 in Object.wait() [109de6000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <7f42b0180> (a java.lang.ref.Reference$Lock)
	at java.lang.Object.wait(Object.java:485)
	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
	- locked <7f42b0180> (a java.lang.ref.Reference$Lock)

"VM Thread" prio=9 tid=1018cc800 nid=0x109ce4000 runnable 

"Gang worker#0 (Parallel GC Threads)" prio=9 tid=101802800 nid=0x10176a000 runnable 

"Gang worker#1 (Parallel GC Threads)" prio=9 tid=101803000 nid=0x102301000 runnable 

"Gang worker#2 (Parallel GC Threads)" prio=9 tid=101803800 nid=0x102404000 runnable 

"Gang worker#3 (Parallel GC Threads)" prio=9 tid=101804000 nid=0x102507000 runnable 

"Concurrent Mark-Sweep GC Thread" prio=9 tid=10187f800 nid=0x1099f0000 runnable 
"VM Periodic Task Thread" prio=10 tid=10281d800 nid=0x10b501000 waiting on condition 

"Exception Catcher Thread" prio=10 tid=101801800 nid=0x100704000 runnable 
JNI global references: 955

Heap
 par new generation   total 19136K, used 6068K [7f3000000, 7f44c0000, 7f44c0000)
  eden space 17024K,  26% used [7f3000000, 7f3457300, 7f40a0000)
  from space 2112K,  76% used [7f42b0000, 7f4445ea8, 7f44c0000)
  to   space 2112K,   0% used [7f40a0000, 7f40a0000, 7f42b0000)
 concurrent mark-sweep generation total 63872K, used 0K [7f44c0000, 7f8320000, 7fae00000)
 concurrent-mark-sweep perm gen total 21248K, used 11850K [7fae00000, 7fc2c0000, 800000000)



> jboss-admin.sh fails to exit when run in single command mode
> ------------------------------------------------------------
>
>                 Key: AS7-1225
>                 URL: https://issues.jboss.org/browse/AS7-1225
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 7.0.0.CR1
>            Reporter: Scott Stark
>
> This seems to be a new behavior, but regardless it is a problem that breaks other frameworks that call out to the command line shell with a single command and expect it to return. Currently it fails to exit, and callers hang. This is true both in the case of the server running with a management interface, and when one is missing:
> [269](ironmaiden:bin) > ./jboss-admin.sh --connect command=:shutdown
> Connected to standalone controller at localhost:9999
> Communication error: Channel closed
> Closed connection to localhost:9999
> ^C
> [270](ironmaiden:bin) > ./jboss-admin.sh --connect command=:shutdown
> The controller is not available at localhost:9999
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> ^C
> When running a mode where the commands to run are from a file or command line, that is, non-interactive mode, the cli should exit with a status.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 17:21:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 7 Jul 2011 17:21:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1225) jboss-admin.sh fails
 to exit when run in single command mode
In-Reply-To: <627196052.40655.1310071463653.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1932631944.40703.1310073683684.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-1225:
----------------------------------

             Assignee: Alexey Loubyansky
    Affects Version/s: 7.0.0.Final
                           (was: 7.0.0.CR1)


> jboss-admin.sh fails to exit when run in single command mode
> ------------------------------------------------------------
>
>                 Key: AS7-1225
>                 URL: https://issues.jboss.org/browse/AS7-1225
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 7.0.0.Final
>            Reporter: Scott Stark
>            Assignee: Alexey Loubyansky
>
> This seems to be a new behavior, but regardless it is a problem that breaks other frameworks that call out to the command line shell with a single command and expect it to return. Currently it fails to exit, and callers hang. This is true both in the case of the server running with a management interface, and when one is missing:
> [269](ironmaiden:bin) > ./jboss-admin.sh --connect command=:shutdown
> Connected to standalone controller at localhost:9999
> Communication error: Channel closed
> Closed connection to localhost:9999
> ^C
> [270](ironmaiden:bin) > ./jboss-admin.sh --connect command=:shutdown
> The controller is not available at localhost:9999
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> ^C
> When running a mode where the commands to run are from a file or command line, that is, non-interactive mode, the cli should exit with a status.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 17:45:31 2011
From: jira-events at lists.jboss.org (Scott Stark (JIRA))
Date: Thu, 7 Jul 2011 17:45:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1225) jboss-admin.sh fails
 to exit when run in single command mode
In-Reply-To: <627196052.40655.1310071463653.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1387714232.40728.1310075131310.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Stark updated AS7-1225:
-----------------------------

    Attachment: CommandLineMain.java.diff


Example patch that allows the client to exit as expected.

> jboss-admin.sh fails to exit when run in single command mode
> ------------------------------------------------------------
>
>                 Key: AS7-1225
>                 URL: https://issues.jboss.org/browse/AS7-1225
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 7.0.0.Final
>            Reporter: Scott Stark
>            Assignee: Alexey Loubyansky
>         Attachments: CommandLineMain.java.diff
>
>
> This seems to be a new behavior, but regardless it is a problem that breaks other frameworks that call out to the command line shell with a single command and expect it to return. Currently it fails to exit, and callers hang. This is true both in the case of the server running with a management interface, and when one is missing:
> [269](ironmaiden:bin) > ./jboss-admin.sh --connect command=:shutdown
> Connected to standalone controller at localhost:9999
> Communication error: Channel closed
> Closed connection to localhost:9999
> ^C
> [270](ironmaiden:bin) > ./jboss-admin.sh --connect command=:shutdown
> The controller is not available at localhost:9999
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> ^C
> When running a mode where the commands to run are from a file or command line, that is, non-interactive mode, the cli should exit with a status.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 18:11:23 2011
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Thu, 7 Jul 2011 18:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (JBEE-86) Add
 LICENSE.txt to binary's META-INF
Message-ID: <2094218357.40737.1310076683817.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Shelly McGowan edited comment on JBEE-86 at 7/7/11 6:09 PM:
------------------------------------------------------------

I'll make the necessary adjustment to the build to be sure the license files are included.  Note, the version being used in most projects is:
jboss-transaction-api_1.1_spec-1.0.0.Final.jar.


jboss-transaction-api_1.1_spec-1.0.1-Beta1.jar was released specifically for the Infinispan team (JBEE-67).
This request prompted a wider discussion of whether all API releases should be OSGi bundles.   In the informal discussions I've participated in, sounded like a good idea.  


      was (Author: shelly.mcgowan):
    I'll make the necessary adjustment to the build to be sure the license files are included.  Note, the version being used in most projects is:
jboss-transaction-api_1.1_spec-1.0.0.Final.jar.


jboss-transactino-api_1.1_spec-1.0.1-Beta1.jar was released specifically for the Infinispan team (JBEE-67).
This request prompted a wider discussion of whether all API releases should be OSGi bundles.   In the informal discussions I've participated in, sounded like a good idea.  

  
> Add LICENSE.txt to binary's META-INF
> ------------------------------------
>
>                 Key: JBEE-86
>                 URL: https://issues.jboss.org/browse/JBEE-86
>             Project: JBoss JavaEE APIs
>          Issue Type: Task
>         Environment: jboss-transaction-api-1.0.1.GA.jar
>            Reporter: Pete Muir
>
> The jboss-transaction-api-1.0.1.GA.jar is missing this file, which is useful as it means a user can easily verify the licensing requirements for dependencies

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 18:39:23 2011
From: jira-events at lists.jboss.org (Martin Vecera (JIRA))
Date: Thu, 7 Jul 2011 18:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1226) Doubled word in
	exception message
Message-ID: <414964790.40760.1310078363613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Doubled word in exception message
---------------------------------

                 Key: AS7-1226
                 URL: https://issues.jboss.org/browse/AS7-1226
             Project: Application Server 7
          Issue Type: Bug
          Components: Server
    Affects Versions: 7.0.0.CR1
            Reporter: Martin Vecera
            Priority: Minor


I had broken EAR deployment and I received the following error which is expected. IMHO there should be only one "class" word in the error message.

Caused by: java.lang.RuntimeException: Error getting reflective information for class >>class<< org.jboss.test.TaskHelper
	at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:70)
	at org.jboss.as.ejb3.deployment.processors.dd.EjbConcurrencyProcessor.checkMethodOverrides(EjbConcurrencyProcessor.java:109)
	at org.jboss.as.ejb3.deployment.processors.dd.EjbConcurrencyProcessor.deploy(EjbConcurrencyProcessor.java:86)
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
	... 5 more


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 20:42:23 2011
From: jira-events at lists.jboss.org (Gerry Matte (JIRA))
Date: Thu, 7 Jul 2011 20:42:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1227) AJP 1.3 Connector not
	working
Message-ID: <384303877.40850.1310085743612.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

AJP 1.3 Connector not working
-----------------------------

                 Key: AS7-1227
                 URL: https://issues.jboss.org/browse/AS7-1227
             Project: Application Server 7
          Issue Type: Bug
          Components: Web Services
    Affects Versions: 7.0.0.CR1
         Environment: Windows 7 x64
            Reporter: Gerry Matte


I have been using Apache with Jboss 6 and the mod_jk connector.  When I attempted to configure Jboss 7 to support the same Apache connector, I followed the directions at https://docs.jboss.org/author/display/AS7/Apache+httpd .

After making the changes, jboss started with no errors.

When I attempted to use http://localhost/jbossTests rather than http://localhost:8080/jbossTests I was presented with a blank screen and no error messages in either the console window or the server.log file..

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 20:46:23 2011
From: jira-events at lists.jboss.org (Gerry Matte (JIRA))
Date: Thu, 7 Jul 2011 20:46:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-1227) AJP 1.3 Connector not
	working
In-Reply-To: <384303877.40850.1310085743612.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1082306168.40852.1310085983654.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Gerry Matte closed AS7-1227.
----------------------------

    Resolution: Done


When I went back and tried again everything worked.

> AJP 1.3 Connector not working
> -----------------------------
>
>                 Key: AS7-1227
>                 URL: https://issues.jboss.org/browse/AS7-1227
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.CR1
>         Environment: Windows 7 x64
>            Reporter: Gerry Matte
>
> I have been using Apache with Jboss 6 and the mod_jk connector.  When I attempted to configure Jboss 7 to support the same Apache connector, I followed the directions at https://docs.jboss.org/author/display/AS7/Apache+httpd .
> After making the changes, jboss started with no errors.
> When I attempted to use http://localhost/jbossTests rather than http://localhost:8080/jbossTests I was presented with a blank screen and no error messages in either the console window or the server.log file..

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 20:50:23 2011
From: jira-events at lists.jboss.org (Gerry Matte (JIRA))
Date: Thu, 7 Jul 2011 20:50:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1227) AJP 1.3 Connector
	not working
In-Reply-To: <384303877.40850.1310085743612.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <390318910.40859.1310086223715.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Gerry Matte commented on AS7-1227:
----------------------------------

It seems that the URL must now end with a trailing slash whereas for prior versions of jboss that was not a requirement.  It works if I use the URL http://localhost/jbossTests/

Is that a bug ? 

> AJP 1.3 Connector not working
> -----------------------------
>
>                 Key: AS7-1227
>                 URL: https://issues.jboss.org/browse/AS7-1227
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.CR1
>         Environment: Windows 7 x64
>            Reporter: Gerry Matte
>
> I have been using Apache with Jboss 6 and the mod_jk connector.  When I attempted to configure Jboss 7 to support the same Apache connector, I followed the directions at https://docs.jboss.org/author/display/AS7/Apache+httpd .
> After making the changes, jboss started with no errors.
> When I attempted to use http://localhost/jbossTests rather than http://localhost:8080/jbossTests I was presented with a blank screen and no error messages in either the console window or the server.log file..

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 20:52:23 2011
From: jira-events at lists.jboss.org (Gerry Matte (JIRA))
Date: Thu, 7 Jul 2011 20:52:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (AS7-1227) AJP 1.3 Connector
	not working
In-Reply-To: <384303877.40850.1310085743612.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1729613037.40863.1310086343705.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Gerry Matte reopened AS7-1227:
------------------------------



> AJP 1.3 Connector not working
> -----------------------------
>
>                 Key: AS7-1227
>                 URL: https://issues.jboss.org/browse/AS7-1227
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.CR1
>         Environment: Windows 7 x64
>            Reporter: Gerry Matte
>
> I have been using Apache with Jboss 6 and the mod_jk connector.  When I attempted to configure Jboss 7 to support the same Apache connector, I followed the directions at https://docs.jboss.org/author/display/AS7/Apache+httpd .
> After making the changes, jboss started with no errors.
> When I attempted to use http://localhost/jbossTests rather than http://localhost:8080/jbossTests I was presented with a blank screen and no error messages in either the console window or the server.log file..

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 22:29:23 2011
From: jira-events at lists.jboss.org (stevearoonie (JIRA))
Date: Thu, 7 Jul 2011 22:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3122) Classloading
 error with AspectJ and Drools 5.2.0.Final
Message-ID: <1051414703.40908.1310092163626.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Classloading error with AspectJ and Drools 5.2.0.Final
------------------------------------------------------

                 Key: JBRULES-3122
                 URL: https://issues.jboss.org/browse/JBRULES-3122
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.2.0.Final
            Reporter: stevearoonie
            Assignee: Mark Proctor


NPE running Drools with AspectJ

java.lang.NullPointerException
at org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.parseDefinitions(ClassLoaderWeavingAdaptor.java:251)
at org.aspectj.weaver.loadtime.DefaultWeavingContext.getDefinitions(DefaultWeavingContext.java:130)
at org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.initialize(ClassLoaderWeavingAdaptor.java:161)
at org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor.initialize(Aj.java:271)
at org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor.getWeavingAdaptor(Aj.java:276)
at org.aspectj.weaver.loadtime.Aj$WeaverContainer.getWeaver(Aj.java:254)
at org.aspectj.weaver.loadtime.Aj.preProcess(Aj.java:90)
at org.aspectj.weaver.loadtime.ClassPreProcessorAgentAdapter.transform(ClassPreProcessorAgentAdapter.java:54)
at sun.instrument.TransformerManager.transform(TransformerManager.java:169)
at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:365)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at org.drools.rule.JavaDialectRuntimeData$PackageClassLoader.fastFindClass(JavaDialectRuntimeData.java:570)
at org.drools.util.CompositeClassLoader$CachingLoader.load(CompositeClassLoader.java:258)
at org.drools.util.CompositeClassLoader$CachingLoader.load(CompositeClassLoader.java:241)
at org.drools.util.CompositeClassLoader.loadClass(CompositeClassLoader.java:88)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at org.drools.rule.JavaDialectRuntimeData.wire(JavaDialectRuntimeData.java:405)
at org.drools.rule.JavaDialectRuntimeData.wire(JavaDialectRuntimeData.java:396)
at org.drools.rule.JavaDialectRuntimeData.onBeforeExecute(JavaDialectRuntimeData.java:237)
at org.drools.rule.DialectRuntimeRegistry.onBeforeExecute(DialectRuntimeRegistry.java:132)
at org.drools.compiler.PackageBuilder.reloadAll(PackageBuilder.java:796)
at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:751)
at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:360)
at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:538)
at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:28)
at au.com.promedicus.rules.KnowledgeBaseBuilder.addPackagesFromList(KnowledgeBaseBuilder.java:108)
at au.com.promedicus.rules.KnowledgeBaseBuilder.build(KnowledgeBaseBuilder.java:69)
at au.com.promedicus.rules.KnowledgeBaseBuilder.build(KnowledgeBaseBuilder.java:54)


I have traced the problem to org.drools.rule.JavaDialectRuntimeData$PackageClassLoader.getResources. This returns null whereas AspectJ expects it to at least return an empty enumeration - hence the NPE.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul  7 23:58:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 7 Jul 2011 23:58:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1228) Resource injection
 does not work for servlets defined in a different module
Message-ID: <842608069.40918.1310097503726.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Resource injection does not work for servlets defined in a different module
---------------------------------------------------------------------------

                 Key: AS7-1228
                 URL: https://issues.jboss.org/browse/AS7-1228
             Project: Application Server 7
          Issue Type: Bug
    Affects Versions: 7.0.0.CR1
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 00:00:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 8 Jul 2011 00:00:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1190) Spring Loading not
	documented
In-Reply-To: <1365360286.35366.1309877243952.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1617357628.40924.1310097623859.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on AS7-1190:
-----------------------------------

Hi Jim,

What kind of class loader isolation are you looking for? Typically, in AS7 users can package the libraries of their choice within their application and have it picked up by the server.

Some documentation is here https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7 and also in this forum thread http://community.jboss.org/message/608887#608887. 

Is that what you are looking for?


> Spring Loading not documented
> -----------------------------
>
>                 Key: AS7-1190
>                 URL: https://issues.jboss.org/browse/AS7-1190
>             Project: Application Server 7
>          Issue Type: Feature Request
>            Reporter: Jim Tyrrell
>
> Since Jason in the video I watched mentioned that class loading isolation was a setting and I have a customer provided Spring/hibernate war file provided, I would like to explore these settings, but I can not seem to find where they are documented.  I would think since it was mentioned in the webinar this is a blocker. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 00:17:23 2011
From: jira-events at lists.jboss.org (stevearoonie (JIRA))
Date: Fri, 8 Jul 2011 00:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3122) Classloading
 error with AspectJ and Drools 5.2.0.Final
In-Reply-To: <1051414703.40908.1310092163626.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <966103955.40984.1310098643687.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

stevearoonie commented on JBRULES-3122:
---------------------------------------

possibly should return getParent().getResources

> Classloading error with AspectJ and Drools 5.2.0.Final
> ------------------------------------------------------
>
>                 Key: JBRULES-3122
>                 URL: https://issues.jboss.org/browse/JBRULES-3122
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.2.0.Final
>            Reporter: stevearoonie
>            Assignee: Mark Proctor
>
> NPE running Drools with AspectJ
> java.lang.NullPointerException
> at org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.parseDefinitions(ClassLoaderWeavingAdaptor.java:251)
> at org.aspectj.weaver.loadtime.DefaultWeavingContext.getDefinitions(DefaultWeavingContext.java:130)
> at org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.initialize(ClassLoaderWeavingAdaptor.java:161)
> at org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor.initialize(Aj.java:271)
> at org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor.getWeavingAdaptor(Aj.java:276)
> at org.aspectj.weaver.loadtime.Aj$WeaverContainer.getWeaver(Aj.java:254)
> at org.aspectj.weaver.loadtime.Aj.preProcess(Aj.java:90)
> at org.aspectj.weaver.loadtime.ClassPreProcessorAgentAdapter.transform(ClassPreProcessorAgentAdapter.java:54)
> at sun.instrument.TransformerManager.transform(TransformerManager.java:169)
> at sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:365)
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
> at org.drools.rule.JavaDialectRuntimeData$PackageClassLoader.fastFindClass(JavaDialectRuntimeData.java:570)
> at org.drools.util.CompositeClassLoader$CachingLoader.load(CompositeClassLoader.java:258)
> at org.drools.util.CompositeClassLoader$CachingLoader.load(CompositeClassLoader.java:241)
> at org.drools.util.CompositeClassLoader.loadClass(CompositeClassLoader.java:88)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
> at org.drools.rule.JavaDialectRuntimeData.wire(JavaDialectRuntimeData.java:405)
> at org.drools.rule.JavaDialectRuntimeData.wire(JavaDialectRuntimeData.java:396)
> at org.drools.rule.JavaDialectRuntimeData.onBeforeExecute(JavaDialectRuntimeData.java:237)
> at org.drools.rule.DialectRuntimeRegistry.onBeforeExecute(DialectRuntimeRegistry.java:132)
> at org.drools.compiler.PackageBuilder.reloadAll(PackageBuilder.java:796)
> at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:751)
> at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:360)
> at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:538)
> at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:28)
> at au.com.promedicus.rules.KnowledgeBaseBuilder.addPackagesFromList(KnowledgeBaseBuilder.java:108)
> at au.com.promedicus.rules.KnowledgeBaseBuilder.build(KnowledgeBaseBuilder.java:69)
> at au.com.promedicus.rules.KnowledgeBaseBuilder.build(KnowledgeBaseBuilder.java:54)
> I have traced the problem to org.drools.rule.JavaDialectRuntimeData$PackageClassLoader.getResources. This returns null whereas AspectJ expects it to at least return an empty enumeration - hence the NPE.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 01:06:23 2011
From: jira-events at lists.jboss.org (Jim Tyrrell (JIRA))
Date: Fri, 8 Jul 2011 01:06:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1190) Spring Loading not
	documented
In-Reply-To: <1365360286.35366.1309877243952.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <628002112.41051.1310101583694.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jim Tyrrell commented on AS7-1190:
----------------------------------

I would think those pages would have instructions on what it takes to run:
my own hibernate version that I have shipped in my war for years
my own random jar files, that we happen to use, different versions in our app container
spring jar files that require some magic to run

I would think the above, could/should:
Generate clear error messages pointing me to good googleable terms to search on how to fix things, ie error codes.
Might even change how the application is loaded, and tell me what to change config file wise.
Something else, not sure what that is.

I would think some documentation around class loaded isolation would be provided, if that is what is required.  I have to admit I am so lost with the thin documentation, I am not even sure what I am asking for.  Is it enough to ask for war file first class loaded, I just don't know.  Sorry.

I have some instructions that I need to try from this thread from earlier today, that I was sent privately, and need to make sense of them.  I do not think the instructions as they sit above get me on the path to what I need based on what I have in that email, so we have a gap, but I do not know enough to write that up just yet.

Let me play with that stuff tomorrow and maybe I will look at it in the context of these docs, and try to make some sense of this all.

The other comments on the docs, we are mixing ear, war, Class Loading Precedence, Automatic Dependencies and more in other words we are crossing so many things, I get lost as to what pieces go with what other pieces, just as has been a problem with our docs since the beginning of time.  Not sure how we fix that.  I call it the kitchen sink, we kinda document everything, in the hopes it covers what users need, and in my experience that has not worked for our paying customers.

> Spring Loading not documented
> -----------------------------
>
>                 Key: AS7-1190
>                 URL: https://issues.jboss.org/browse/AS7-1190
>             Project: Application Server 7
>          Issue Type: Feature Request
>            Reporter: Jim Tyrrell
>
> Since Jason in the video I watched mentioned that class loading isolation was a setting and I have a customer provided Spring/hibernate war file provided, I would like to explore these settings, but I can not seem to find where they are documented.  I would think since it was mentioned in the webinar this is a blocker. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 01:29:23 2011
From: jira-events at lists.jboss.org (Takayoshi Kimura (JIRA))
Date: Fri, 8 Jul 2011 01:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-237) Improve
 ClusterChooserInterceptor exception messages
In-Reply-To: <31712902.1244580236721.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1888195590.41060.1310102963777.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Takayoshi Kimura reassigned JBCLUSTER-237:
------------------------------------------

    Assignee: Takayoshi Kimura  (was: Brian Stansberry)


> Improve ClusterChooserInterceptor exception messages
> ----------------------------------------------------
>
>                 Key: JBCLUSTER-237
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-237
>             Project: JBoss Clustering
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: HA-Client
>            Reporter: Brian Stansberry
>            Assignee: Takayoshi Kimura
>            Priority: Minor
>             Fix For: HA-Client 2.0.0.BETA1
>
>
> Stuff like the following needs improvement:
> target = (InvokerLocator) lb.chooseTarget(family.get());
>          if (target == null)
>          {
>             if (lastException != null)
>             {
>                throw new RuntimeException("cluster invocation failed, last exception was: ", lastException);
>             }
>             else
>             {
>                throw new RuntimeException("cluster invocation failed");
>             }
>          }
>          failoverCounter++;
>       }
>       // if we get here this means list was exhausted
>       throw new RuntimeException("Unreachable?: Service unavailable.");

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 01:33:23 2011
From: jira-events at lists.jboss.org (Takayoshi Kimura (JIRA))
Date: Fri, 8 Jul 2011 01:33:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-237) Improve
 ClusterChooserInterceptor exception messages
In-Reply-To: <31712902.1244580236721.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <851148025.41064.1310103203666.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Takayoshi Kimura reassigned JBCLUSTER-237:
------------------------------------------

    Assignee: Brian Stansberry  (was: Takayoshi Kimura)


Sorry for the noise. It was assigned to me by just single misclick without any confirmation :(

> Improve ClusterChooserInterceptor exception messages
> ----------------------------------------------------
>
>                 Key: JBCLUSTER-237
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-237
>             Project: JBoss Clustering
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: HA-Client
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: HA-Client 2.0.0.BETA1
>
>
> Stuff like the following needs improvement:
> target = (InvokerLocator) lb.chooseTarget(family.get());
>          if (target == null)
>          {
>             if (lastException != null)
>             {
>                throw new RuntimeException("cluster invocation failed, last exception was: ", lastException);
>             }
>             else
>             {
>                throw new RuntimeException("cluster invocation failed");
>             }
>          }
>          failoverCounter++;
>       }
>       // if we get here this means list was exhausted
>       throw new RuntimeException("Unreachable?: Service unavailable.");

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 02:03:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Fri, 8 Jul 2011 02:03:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1229) XML parser changes
 broke the seam booking example
Message-ID: <533966840.41103.1310105003922.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

XML parser changes broke the seam booking example
-------------------------------------------------

                 Key: AS7-1229
                 URL: https://issues.jboss.org/browse/AS7-1229
             Project: Application Server 7
          Issue Type: Bug
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas


java.lang.RuntimeException: java.lang.ClassNotFoundException: com.sun.org.apache.xerces.internal.parsers.SAXParser from [Module \"deployment.seam-booking.war:main\" from Service Module Loader]
        at org.jboss.seam.config.xml.parser.ParserMain.parse(ParserMain.java:70)
        at org.jboss.seam.config.xml.bootstrap.XmlConfigExtension.beforeBeanDiscovery(XmlConfigExtension.java:97)
        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.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
        at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
        at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
        at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
        at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
        at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
        at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
        at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:282)
        at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:265)
        at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234)
        at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:88)
        at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:52)
        at org.jboss.weld.bootstrap.events.BeforeBeanDiscoveryImpl.fire(BeforeBeanDiscoveryImpl.java:48)
        at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:351)
        at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:80)
        at org.jboss.as.weld.services.WeldService.start(WeldService.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)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:680)
Caused by: java.lang.ClassNotFoundException: com.sun.org.apache.xerces.internal.parsers.SAXParser from [Module \"deployment.seam-booking.war:main\" from Service Module Loader]
        at org.xml.sax.helpers.XMLReaderFactory.loadClass(XMLReaderFactory.java:189)
        at org.xml.sax.helpers.XMLReaderFactory.createXMLReader(XMLReaderFactory.java:150)
        at org.jboss.seam.config.xml.parser.ParserMain.parse(ParserMain.java:62)
        ... 26 more
Caused by: java.lang.ClassNotFoundException: com.sun.org.apache.xerces.internal.parsers.SAXParser from [Module \"deployment.seam-booking.war:main\" from Service Module Loader]
        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
        at org.xml.sax.helpers.NewInstance.newInstance(NewInstance.java:49)
        at org.xml.sax.helpers.XMLReaderFactory.loadClass(XMLReaderFactory.java:187)
        ... 28 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 02:14:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Fri, 8 Jul 2011 02:14:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1229) XML parser changes
 broke the seam booking example
In-Reply-To: <533966840.41103.1310105003922.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <360388633.41150.1310105663622.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved AS7-1229.
---------------------------------

    Resolution: Out of Date


Already fixed in upstream

> XML parser changes broke the seam booking example
> -------------------------------------------------
>
>                 Key: AS7-1229
>                 URL: https://issues.jboss.org/browse/AS7-1229
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> java.lang.RuntimeException: java.lang.ClassNotFoundException: com.sun.org.apache.xerces.internal.parsers.SAXParser from [Module \"deployment.seam-booking.war:main\" from Service Module Loader]
>         at org.jboss.seam.config.xml.parser.ParserMain.parse(ParserMain.java:70)
>         at org.jboss.seam.config.xml.bootstrap.XmlConfigExtension.beforeBeanDiscovery(XmlConfigExtension.java:97)
>         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.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
>         at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
>         at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
>         at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
>         at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
>         at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
>         at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
>         at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:282)
>         at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:265)
>         at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234)
>         at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:88)
>         at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:52)
>         at org.jboss.weld.bootstrap.events.BeforeBeanDiscoveryImpl.fire(BeforeBeanDiscoveryImpl.java:48)
>         at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:351)
>         at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:80)
>         at org.jboss.as.weld.services.WeldService.start(WeldService.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)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:680)
> Caused by: java.lang.ClassNotFoundException: com.sun.org.apache.xerces.internal.parsers.SAXParser from [Module \"deployment.seam-booking.war:main\" from Service Module Loader]
>         at org.xml.sax.helpers.XMLReaderFactory.loadClass(XMLReaderFactory.java:189)
>         at org.xml.sax.helpers.XMLReaderFactory.createXMLReader(XMLReaderFactory.java:150)
>         at org.jboss.seam.config.xml.parser.ParserMain.parse(ParserMain.java:62)
>         ... 26 more
> Caused by: java.lang.ClassNotFoundException: com.sun.org.apache.xerces.internal.parsers.SAXParser from [Module \"deployment.seam-booking.war:main\" from Service Module Loader]
>         at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
>         at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
>         at org.xml.sax.helpers.NewInstance.newInstance(NewInstance.java:49)
>         at org.xml.sax.helpers.XMLReaderFactory.loadClass(XMLReaderFactory.java:187)
>         ... 28 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 02:22:37 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Fri, 8 Jul 2011 02:22:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1216)
 NonexistentConversationException when attempting to restore a long-running
 conversation on AS 7 CR1 and not beta3
In-Reply-To: <1250756013.38439.1309992443679.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <719622812.41189.1310106157713.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas commented on AS7-1216:
-------------------------------------

Do you have an example webapp that reproduces the problem?

> NonexistentConversationException when attempting to restore a long-running conversation on AS 7 CR1 and not beta3
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1216
>                 URL: https://issues.jboss.org/browse/AS7-1216
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 7.0.0.CR1
>         Environment: Windows XP 32 bit, JBoss AS 7 CR1 and Firefox 5
>            Reporter: Drew Stockdreher
>
> A simple web application which starts a long-running conversation via an 
> <f:event type="preRenderView" listener="#{bean.startConvo}"/> tag. 
>  Selecting from a selectOneMenuList makes an ajax request which was working on the beta3 release of AS 7 is no longer working with the following stacktrace.  This does however still work in IE 7 and Chrome 12 on both beta3 and CR1 releases. 
> 10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1) org.jboss.weld.context.NonexistentConversationException: WELD-000321 No conversation found to restore for id 1
> 10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.jboss.weld.jsf.WeldPhaseListener.activateConversations(WeldPhaseListener.java:108)
> 10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.jboss.weld.jsf.WeldPhaseListener.beforePhase(WeldPhaseListener.java:84)
> 10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1)    at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228)
> 10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1)    at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99)
> 10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1)    at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:111)
> 10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1)    at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
> 10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1)    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312)
> 10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> 10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67)
> 10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
> 10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> 10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> 10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
> 10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49)
> 10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
> 10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
> 10:36:11,322 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> 10:36:11,322 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667)
> 10:36:11,322 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951)
> 10:36:11,322 ERROR [stderr] (http--127.0.0.1-8080-1)    at java.lang.Thread.run(Thread.java:662)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 02:24:23 2011
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 8 Jul 2011 02:24:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1344) Replace
 ChannelException with Exception
Message-ID: <1718526036.41193.1310106263625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Replace ChannelException with Exception
---------------------------------------

                 Key: JGRP-1344
                 URL: https://issues.jboss.org/browse/JGRP-1344
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.0


public void JChannel.connect(String cluster) throws ChannelException --> throws Exception

This is more generic, and we can still throw ChannelClosedExceptions (needs to be listed in the javadoc)

This way, we don't have to wrap an Exception received from state transfer (fetching state or setting state) into a StateTransferException

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 04:43:23 2011
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Fri, 8 Jul 2011 04:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JASSIST-143) Getting an
 exception NotFoundException
In-Reply-To: <46602331.28404.1309372343718.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1011842793.41377.1310114603871.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Shigeru Chiba resolved JASSIST-143.
-----------------------------------

    Fix Version/s: 3.15.0.GA
       Resolution: Done


Not a bug.

> Getting an exception NotFoundException
> --------------------------------------
>
>                 Key: JASSIST-143
>                 URL: https://issues.jboss.org/browse/JASSIST-143
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.14.0.GA
>         Environment: Windows Vista, Jdk 1.6 
>            Reporter: sagar shinde
>            Assignee: Shigeru Chiba
>             Fix For: 3.15.0.GA
>
>
> I am facing problem in using JavaAssist in Eclipse 3.6.1. I have added the javassist.jar file in the project created in eclipse through buildpath option. My program details r as follows: 
>  // 1st program:
> package temp;
> //import javassist.*;
> public class Hello {
> 	  public void say() {
> 	        System.out.println("Hello");
> 	    }
> 	}
> _________________________________________________________
> 2nd program: 
> package temp;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtMethod;
> public class Test {
>     public static void main(String[] args) throws Exception {
>         ClassPool cp = ClassPool.getDefault();
>         CtClass cc = cp.get("Hello");
>       
>        CtMethod m = cc.getDeclaredMethod("say");
>        m.insertBefore("{ System.out.println(\"Hello.say():\"); }");
>        Class c = cc.toClass();
>       Hello h = (Hello)c.newInstance();
>       h.say();
>         
>         System.out.println("test prog:");
>     }
> }
> Test class while executing shows the error for cp.get() method saying NotFoundException. Whts the error? 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 04:43:24 2011
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Fri, 8 Jul 2011 04:43:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JASSIST-143) Getting an
 exception NotFoundException
In-Reply-To: <46602331.28404.1309372343718.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <278151095.41382.1310114604203.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Shigeru Chiba closed JASSIST-143.
---------------------------------



> Getting an exception NotFoundException
> --------------------------------------
>
>                 Key: JASSIST-143
>                 URL: https://issues.jboss.org/browse/JASSIST-143
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.14.0.GA
>         Environment: Windows Vista, Jdk 1.6 
>            Reporter: sagar shinde
>            Assignee: Shigeru Chiba
>             Fix For: 3.15.0.GA
>
>
> I am facing problem in using JavaAssist in Eclipse 3.6.1. I have added the javassist.jar file in the project created in eclipse through buildpath option. My program details r as follows: 
>  // 1st program:
> package temp;
> //import javassist.*;
> public class Hello {
> 	  public void say() {
> 	        System.out.println("Hello");
> 	    }
> 	}
> _________________________________________________________
> 2nd program: 
> package temp;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtMethod;
> public class Test {
>     public static void main(String[] args) throws Exception {
>         ClassPool cp = ClassPool.getDefault();
>         CtClass cc = cp.get("Hello");
>       
>        CtMethod m = cc.getDeclaredMethod("say");
>        m.insertBefore("{ System.out.println(\"Hello.say():\"); }");
>        Class c = cc.toClass();
>       Hello h = (Hello)c.newInstance();
>       h.say();
>         
>         System.out.println("test prog:");
>     }
> }
> Test class while executing shows the error for cp.get() method saying NotFoundException. Whts the error? 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 04:47:23 2011
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Fri, 8 Jul 2011 04:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JASSIST-110)
 CtClassType.isModified does not check for edited attributes in the
 ClassFile
In-Reply-To: <1925629425.1268319457806.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1980369279.41386.1310114843977.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Shigeru Chiba resolved JASSIST-110.
-----------------------------------

    Fix Version/s: 3.15.0.GA
       Resolution: Done


not a bug.

> CtClassType.isModified does not check for edited attributes in the ClassFile
> ----------------------------------------------------------------------------
>
>                 Key: JASSIST-110
>                 URL: https://issues.jboss.org/browse/JASSIST-110
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.11.0.GA
>            Reporter: Flavia Rainone
>            Assignee: Shigeru Chiba
>             Fix For: 3.15.0.GA
>
>
> If you edit an attribute of a CtClass and call isModified, it will return false. It should return true.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 04:47:24 2011
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Fri, 8 Jul 2011 04:47:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JASSIST-110)
 CtClassType.isModified does not check for edited attributes in the
 ClassFile
In-Reply-To: <1925629425.1268319457806.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <719941116.41390.1310114844132.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Shigeru Chiba closed JASSIST-110.
---------------------------------



> CtClassType.isModified does not check for edited attributes in the ClassFile
> ----------------------------------------------------------------------------
>
>                 Key: JASSIST-110
>                 URL: https://issues.jboss.org/browse/JASSIST-110
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.11.0.GA
>            Reporter: Flavia Rainone
>            Assignee: Shigeru Chiba
>             Fix For: 3.15.0.GA
>
>
> If you edit an attribute of a CtClass and call isModified, it will return false. It should return true.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 04:49:23 2011
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Fri, 8 Jul 2011 04:49:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JASSIST-132) Replacing an
 expression with a try-catch statement
In-Reply-To: <194557019.5211.1283553232515.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1510558717.41395.1310114963856.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Shigeru Chiba closed JASSIST-132.
---------------------------------



> Replacing an expression with a try-catch statement
> --------------------------------------------------
>
>                 Key: JASSIST-132
>                 URL: https://issues.jboss.org/browse/JASSIST-132
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.13.0.GA
>         Environment: JDK 1.6.0_18
>            Reporter: Thomas Mauch
>            Assignee: Shigeru Chiba
>             Fix For: 3.14.0.GA
>
>         Attachments: bug.zip
>
>
> Instrumenting fails with ArrayIndexOutOfBoundsException.
> I will upload a test case showing the issue.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 04:49:24 2011
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Fri, 8 Jul 2011 04:49:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JASSIST-131)
 ClassFileWriter.ConstPoolWriter.addStringInfo() corrupts the ConstPool
In-Reply-To: <890117582.18228.1282645271868.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <430372516.41399.1310114964444.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Shigeru Chiba closed JASSIST-131.
---------------------------------



> ClassFileWriter.ConstPoolWriter.addStringInfo() corrupts the ConstPool
> ----------------------------------------------------------------------
>
>                 Key: JASSIST-131
>                 URL: https://issues.jboss.org/browse/JASSIST-131
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.13.0.GA
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 3.14.0.GA
>
>
> It was mixing the output of itself and the utf info, this fixes it
>          public int addStringInfo(String str) {
> +            int utf8 = addUtf8Info(str);
>              output.write(StringInfo.tag);
> -            output.writeShort(addUtf8Info(str));
> +            output.writeShort(utf8);
>              return num++;
>          }

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 05:11:23 2011
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Fri, 8 Jul 2011 05:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JASSIST-138) CHECKCAST of
 javassist.bytecode.analysis.Executor.execute() is broken
In-Reply-To: <1252497922.40665.1296117769609.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1114648087.41465.1310116283867.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Shigeru Chiba resolved JASSIST-138.
-----------------------------------

    Fix Version/s: 3.15.0.GA
       Resolution: Done


> CHECKCAST of javassist.bytecode.analysis.Executor.execute() is broken
> ---------------------------------------------------------------------
>
>                 Key: JASSIST-138
>                 URL: https://issues.jboss.org/browse/JASSIST-138
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.12.0.GA
>            Reporter: Yu Kobayashi
>            Assignee: Shigeru Chiba
>             Fix For: 3.15.0.GA
>
>
> At execute(MethodInfo method, int pos, CodeIterator iter, Frame frame, Subroutine subroutine) of
> javassist.bytecode.analysis.Executor, CHECKCAST is this.
> case CHECKCAST:
>     verifyAssignable(Type.OBJECT, simplePop(frame));
>     frame.push(typeFromDesc(constPool.getClassInfo(iter.u16bitAt(pos + 1))));
>     break;
> However, constPool.getClassInfo() doesn't returns its descriptor.
> To fix this, please change it to 
> frame.push(typeFromDesc(constPool.getClassInfoByDescriptor(iter.u16bitAt(pos + 1))));
> and add this to javassist.bytecode.ConstPool.
>     public String getClassInfoByDescriptor(int index) {
>         ClassInfo c = (ClassInfo)getItem(index);
>         if (c == null)
>             return null;
>         else {
>         	String className = getUtf8Info(c.name);
>         	if (className.charAt(0) == '[') {
>         		return className;
>         	} else {
>             	return Descriptor.of(className);
>             }
>         }
>     }

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 05:13:23 2011
From: jira-events at lists.jboss.org (Shigeru Chiba (JIRA))
Date: Fri, 8 Jul 2011 05:13:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JASSIST-138) CHECKCAST of
 javassist.bytecode.analysis.Executor.execute() is broken
In-Reply-To: <1252497922.40665.1296117769609.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1279835953.41468.1310116403783.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Shigeru Chiba closed JASSIST-138.
---------------------------------



> CHECKCAST of javassist.bytecode.analysis.Executor.execute() is broken
> ---------------------------------------------------------------------
>
>                 Key: JASSIST-138
>                 URL: https://issues.jboss.org/browse/JASSIST-138
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.12.0.GA
>            Reporter: Yu Kobayashi
>            Assignee: Shigeru Chiba
>             Fix For: 3.15.0.GA
>
>
> At execute(MethodInfo method, int pos, CodeIterator iter, Frame frame, Subroutine subroutine) of
> javassist.bytecode.analysis.Executor, CHECKCAST is this.
> case CHECKCAST:
>     verifyAssignable(Type.OBJECT, simplePop(frame));
>     frame.push(typeFromDesc(constPool.getClassInfo(iter.u16bitAt(pos + 1))));
>     break;
> However, constPool.getClassInfo() doesn't returns its descriptor.
> To fix this, please change it to 
> frame.push(typeFromDesc(constPool.getClassInfoByDescriptor(iter.u16bitAt(pos + 1))));
> and add this to javassist.bytecode.ConstPool.
>     public String getClassInfoByDescriptor(int index) {
>         ClassInfo c = (ClassInfo)getItem(index);
>         if (c == null)
>             return null;
>         else {
>         	String className = getUtf8Info(c.name);
>         	if (className.charAt(0) == '[') {
>         		return className;
>         	} else {
>             	return Descriptor.of(className);
>             }
>         }
>     }

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 06:01:25 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 8 Jul 2011 06:01:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1230) Exception during
 message inflow is not properly logged
Message-ID: <474747820.41547.1310119285570.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Exception during message inflow is not properly logged
------------------------------------------------------

                 Key: AS7-1230
                 URL: https://issues.jboss.org/browse/AS7-1230
             Project: Application Server 7
          Issue Type: Bug
            Reporter: Carlo de Wolf
             Fix For: 7.1.0.CR1


{noformat}
11:56:03,323 ERROR [stderr] (jca-short-running-threads-threads - 2) java.lang.IllegalStateException: No component instance associated
11:56:03,323 ERROR [stderr] (jca-short-running-threads-threads - 2) 	at org.jboss.as.ee.component.ViewDescription$ComponentDispatcherInterceptor.processInvocation(ViewDescription.java:196)
11:56:03,324 ERROR [stderr] (jca-short-running-threads-threads - 2) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
11:56:03,324 ERROR [stderr] (jca-short-running-threads-threads - 2) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
11:56:03,324 ERROR [stderr] (jca-short-running-threads-threads - 2) 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
11:56:03,324 ERROR [stderr] (jca-short-running-threads-threads - 2) 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
11:56:03,324 ERROR [stderr] (jca-short-running-threads-threads - 2) 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
11:56:03,324 ERROR [stderr] (jca-short-running-threads-threads - 2) 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
11:56:03,324 ERROR [stderr] (jca-short-running-threads-threads - 2) 	at org.jboss.as.demos.ejb3.rar.PostmanPat$$$view17.deliver(Unknown Source)
11:56:03,325 ERROR [stderr] (jca-short-running-threads-threads - 2) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
11:56:03,325 ERROR [stderr] (jca-short-running-threads-threads - 2) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
11:56:03,325 ERROR [stderr] (jca-short-running-threads-threads - 2) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
11:56:03,325 ERROR [stderr] (jca-short-running-threads-threads - 2) 	at java.lang.reflect.Method.invoke(Method.java:597)
11:56:03,325 ERROR [stderr] (jca-short-running-threads-threads - 2) 	at org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.doInvoke(MessageEndpointInvocationHandler.java:140)
11:56:03,325 ERROR [stderr] (jca-short-running-threads-threads - 2) 	at org.jboss.as.ejb3.inflow.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:73)
11:56:03,325 ERROR [stderr] (jca-short-running-threads-threads - 2) 	at $Proxy19.deliver(Unknown Source)
11:56:03,326 ERROR [stderr] (jca-short-running-threads-threads - 2) 	at org.jboss.as.demos.ejb3.rar.SimpleQueueResourceAdapter.process(SimpleQueueResourceAdapter.java:112)
11:56:03,326 ERROR [stderr] (jca-short-running-threads-threads - 2) 	at org.jboss.as.demos.ejb3.rar.SimpleQueueResourceAdapter.access$000(SimpleQueueResourceAdapter.java:51)
11:56:03,326 ERROR [stderr] (jca-short-running-threads-threads - 2) 	at org.jboss.as.demos.ejb3.rar.SimpleQueueResourceAdapter$1.run(SimpleQueueResourceAdapter.java:79)
11:56:03,326 ERROR [stderr] (jca-short-running-threads-threads - 2) 	at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:211)
11:56:03,326 ERROR [stderr] (jca-short-running-threads-threads - 2) 	at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)
11:56:03,327 ERROR [stderr] (jca-short-running-threads-threads - 2) 	at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:801)
11:56:03,327 ERROR [stderr] (jca-short-running-threads-threads - 2) 	at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)
11:56:03,327 ERROR [stderr] (jca-short-running-threads-threads - 2) 	at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:821)
11:56:03,327 ERROR [stderr] (jca-short-running-threads-threads - 2) 	at java.lang.Thread.run(Thread.java:662)
11:56:03,327 ERROR [stderr] (jca-short-running-threads-threads - 2) 	at org.jboss.threads.JBossThread.run(JBossThread.java:122)
{noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 06:23:23 2011
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Fri, 8 Jul 2011 06:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1203) test for missing
 xa-datasource properties
In-Reply-To: <1239715458.37294.1309955003698.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1235671506.41566.1310120603735.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jeff Zhang reassigned AS7-1203:
-------------------------------

    Assignee: Jeff Zhang


> test for missing xa-datasource properties
> -----------------------------------------
>
>                 Key: AS7-1203
>                 URL: https://issues.jboss.org/browse/AS7-1203
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: Test Suite
>            Reporter: Stefano Maestri
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 06:23:23 2011
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Fri, 8 Jul 2011 06:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1204) test for properties
 exception sorter, valid & stale connection checkers aren't stored
In-Reply-To: <1958462756.37297.1309955123728.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1501202423.41570.1310120603927.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jeff Zhang reassigned AS7-1204:
-------------------------------

    Assignee: Jeff Zhang


> test for properties exception sorter, valid & stale connection checkers aren't stored
> -------------------------------------------------------------------------------------
>
>                 Key: AS7-1204
>                 URL: https://issues.jboss.org/browse/AS7-1204
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: Test Suite
>            Reporter: Stefano Maestri
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 06:23:24 2011
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Fri, 8 Jul 2011 06:23:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1207) test for not
 persisted (xa)datasource properties
In-Reply-To: <458762522.37319.1309955483781.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1560204817.41574.1310120604396.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jeff Zhang reassigned AS7-1207:
-------------------------------

    Assignee: Jeff Zhang


> test for not persisted (xa)datasource properties
> ------------------------------------------------
>
>                 Key: AS7-1207
>                 URL: https://issues.jboss.org/browse/AS7-1207
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: Test Suite
>            Reporter: Stefano Maestri
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 08:15:31 2011
From: jira-events at lists.jboss.org (Tom Fonteyne (JIRA))
Date: Fri, 8 Jul 2011 08:15:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCLUSTER-295) allows to have a
 "prefered" JBoss server to be picked first if its available
Message-ID: <2141283931.41780.1310127331489.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

allows to have a "prefered" JBoss server to be picked first if its available
----------------------------------------------------------------------------

                 Key: JBCLUSTER-295
                 URL: https://issues.jboss.org/browse/JBCLUSTER-295
             Project: JBoss Clustering
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: HA-Client
    Affects Versions: HA-Client 1.1.1.GA
         Environment: all
            Reporter: Tom Fonteyne
            Assignee: Brian Stansberry
            Priority: Minor


the scenario consists of a front loadbalancer to a number of Tomcat (or I guess Apache) instances which act as front end to a jboss cluster.

Each 'front' (tomcat) and 'back' (jboss)  lives as a pair on a single machine.
The idea is: have the 'front' always contact the local (preferred) 'back' ... and only contact one of the other jboss instances (other boxex) if the local one is not available.

Attached is proposed code that accomplishes this

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 08:17:23 2011
From: jira-events at lists.jboss.org (Tom Fonteyne (JIRA))
Date: Fri, 8 Jul 2011 08:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCLUSTER-295) allows to have a
 "prefered" JBoss server to be picked first if its available
In-Reply-To: <2141283931.41780.1310127331489.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <604780967.41786.1310127443770.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Tom Fonteyne updated JBCLUSTER-295:
-----------------------------------

    Attachment: Preferred.java


> allows to have a "prefered" JBoss server to be picked first if its available
> ----------------------------------------------------------------------------
>
>                 Key: JBCLUSTER-295
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-295
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: HA-Client
>    Affects Versions: HA-Client 1.1.1.GA
>         Environment: all
>            Reporter: Tom Fonteyne
>            Assignee: Brian Stansberry
>            Priority: Minor
>              Labels: jboss
>         Attachments: Preferred.java, PreferredRoundRobin.java
>
>
> the scenario consists of a front loadbalancer to a number of Tomcat (or I guess Apache) instances which act as front end to a jboss cluster.
> Each 'front' (tomcat) and 'back' (jboss)  lives as a pair on a single machine.
> The idea is: have the 'front' always contact the local (preferred) 'back' ... and only contact one of the other jboss instances (other boxex) if the local one is not available.
> Attached is proposed code that accomplishes this

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 08:17:23 2011
From: jira-events at lists.jboss.org (Tom Fonteyne (JIRA))
Date: Fri, 8 Jul 2011 08:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCLUSTER-295) allows to have a
 "prefered" JBoss server to be picked first if its available
In-Reply-To: <2141283931.41780.1310127331489.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <871767160.41790.1310127443901.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Tom Fonteyne updated JBCLUSTER-295:
-----------------------------------

    Attachment: PreferredRoundRobin.java


> allows to have a "prefered" JBoss server to be picked first if its available
> ----------------------------------------------------------------------------
>
>                 Key: JBCLUSTER-295
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-295
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: HA-Client
>    Affects Versions: HA-Client 1.1.1.GA
>         Environment: all
>            Reporter: Tom Fonteyne
>            Assignee: Brian Stansberry
>            Priority: Minor
>              Labels: jboss
>         Attachments: Preferred.java, PreferredRoundRobin.java
>
>
> the scenario consists of a front loadbalancer to a number of Tomcat (or I guess Apache) instances which act as front end to a jboss cluster.
> Each 'front' (tomcat) and 'back' (jboss)  lives as a pair on a single machine.
> The idea is: have the 'front' always contact the local (preferred) 'back' ... and only contact one of the other jboss instances (other boxex) if the local one is not available.
> Attached is proposed code that accomplishes this

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 08:44:23 2011
From: jira-events at lists.jboss.org (Quentin Caillard (JIRA))
Date: Fri, 8 Jul 2011 08:44:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3123) .rf file raises a
 null pointer exception when it is loaded
Message-ID: <1509811794.41878.1310129063858.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

.rf file raises a null pointer exception when it is loaded
----------------------------------------------------------

                 Key: JBRULES-3123
                 URL: https://issues.jboss.org/browse/JBRULES-3123
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.2.0.Final
            Reporter: Quentin Caillard
            Assignee: Mark Proctor


I have just switched from version 5.1.1 to 5.2.0.Final

I have a ruleflow (.rf) file which can be loaded. I have the following stack trace :

java.lang.NullPointerException
	at org.drools.compiler.PackageBuilder.addProcessFromXml(PackageBuilder.java:516)
	at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:556)
	at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:28)
	at com.ariadnext.NewDroolsTest$RulesUtils.loadRules(NewDroolsTest.java:106)

I made a simple junit test which reproduces the bug.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 08:48:23 2011
From: jira-events at lists.jboss.org (Quentin Caillard (JIRA))
Date: Fri, 8 Jul 2011 08:48:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-3123) .rf file raises a
 null pointer exception when it is loaded
In-Reply-To: <1509811794.41878.1310129063858.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2084473187.41895.1310129303741.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Quentin Caillard updated JBRULES-3123:
--------------------------------------

    Attachment: jUnitTest.tar.gz


> .rf file raises a null pointer exception when it is loaded
> ----------------------------------------------------------
>
>                 Key: JBRULES-3123
>                 URL: https://issues.jboss.org/browse/JBRULES-3123
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.2.0.Final
>            Reporter: Quentin Caillard
>            Assignee: Mark Proctor
>         Attachments: jUnitTest.tar.gz
>
>
> I have just switched from version 5.1.1 to 5.2.0.Final
> I have a ruleflow (.rf) file which can be loaded. I have the following stack trace :
> java.lang.NullPointerException
> 	at org.drools.compiler.PackageBuilder.addProcessFromXml(PackageBuilder.java:516)
> 	at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:556)
> 	at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:28)
> 	at com.ariadnext.NewDroolsTest$RulesUtils.loadRules(NewDroolsTest.java:106)
> I made a simple junit test which reproduces the bug.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 08:54:23 2011
From: jira-events at lists.jboss.org (Quentin Caillard (JIRA))
Date: Fri, 8 Jul 2011 08:54:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-3123) .rf file raises a
 null pointer exception when it is loaded
In-Reply-To: <1509811794.41878.1310129063858.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <469245328.41938.1310129663831.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Quentin Caillard updated JBRULES-3123:
--------------------------------------

    Attachment: jUnitTest.tar.gz


> .rf file raises a null pointer exception when it is loaded
> ----------------------------------------------------------
>
>                 Key: JBRULES-3123
>                 URL: https://issues.jboss.org/browse/JBRULES-3123
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.2.0.Final
>            Reporter: Quentin Caillard
>            Assignee: Mark Proctor
>         Attachments: jUnitTest.tar.gz, jUnitTest.tar.gz
>
>
> I have just switched from version 5.1.1 to 5.2.0.Final
> I have a ruleflow (.rf) file which can be loaded. I have the following stack trace :
> java.lang.NullPointerException
> 	at org.drools.compiler.PackageBuilder.addProcessFromXml(PackageBuilder.java:516)
> 	at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:556)
> 	at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:28)
> 	at com.ariadnext.NewDroolsTest$RulesUtils.loadRules(NewDroolsTest.java:106)
> I made a simple junit test which reproduces the bug.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 08:54:24 2011
From: jira-events at lists.jboss.org (Quentin Caillard (JIRA))
Date: Fri, 8 Jul 2011 08:54:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3123) .rf file raises
 a null pointer exception when it is loaded
In-Reply-To: <1509811794.41878.1310129063858.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1052115057.41942.1310129664403.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Quentin Caillard commented on JBRULES-3123:
-------------------------------------------

Take the more recent file. I made a mistake in the first one.

> .rf file raises a null pointer exception when it is loaded
> ----------------------------------------------------------
>
>                 Key: JBRULES-3123
>                 URL: https://issues.jboss.org/browse/JBRULES-3123
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.2.0.Final
>            Reporter: Quentin Caillard
>            Assignee: Mark Proctor
>         Attachments: jUnitTest.tar.gz, jUnitTest.tar.gz
>
>
> I have just switched from version 5.1.1 to 5.2.0.Final
> I have a ruleflow (.rf) file which can be loaded. I have the following stack trace :
> java.lang.NullPointerException
> 	at org.drools.compiler.PackageBuilder.addProcessFromXml(PackageBuilder.java:516)
> 	at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:556)
> 	at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:28)
> 	at com.ariadnext.NewDroolsTest$RulesUtils.loadRules(NewDroolsTest.java:106)
> I made a simple junit test which reproduces the bug.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 09:10:24 2011
From: jira-events at lists.jboss.org (Quentin Caillard (JIRA))
Date: Fri, 8 Jul 2011 09:10:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-3123) .rf file raises a
 null pointer exception when it is loaded
In-Reply-To: <1509811794.41878.1310129063858.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <346967102.41981.1310130624028.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Quentin Caillard updated JBRULES-3123:
--------------------------------------

    Description: 
I have just switched from version 5.1.1 to 5.2.0.Final

I have a ruleflow (.rf) file which can be loaded. I have the following stack trace :
java.lang.NullPointerException
	at org.drools.compiler.PackageBuilder.addProcessFromXml(PackageBuilder.java:516)
	at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:556)
	at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:28)
	at com.ariadnext.NewDroolsTest$RulesUtils.loadRules(NewDroolsTest.java:107)

I made a simple junit test which reproduces the bug.

  was:
I have just switched from version 5.1.1 to 5.2.0.Final

I have a ruleflow (.rf) file which can be loaded. I have the following stack trace :

java.lang.NullPointerException
	at org.drools.compiler.PackageBuilder.addProcessFromXml(PackageBuilder.java:516)
	at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:556)
	at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:28)
	at com.ariadnext.NewDroolsTest$RulesUtils.loadRules(NewDroolsTest.java:106)

I made a simple junit test which reproduces the bug.



> .rf file raises a null pointer exception when it is loaded
> ----------------------------------------------------------
>
>                 Key: JBRULES-3123
>                 URL: https://issues.jboss.org/browse/JBRULES-3123
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.2.0.Final
>            Reporter: Quentin Caillard
>            Assignee: Mark Proctor
>         Attachments: jUnitTest.tar.gz, jUnitTest.tar.gz
>
>
> I have just switched from version 5.1.1 to 5.2.0.Final
> I have a ruleflow (.rf) file which can be loaded. I have the following stack trace :
> java.lang.NullPointerException
> 	at org.drools.compiler.PackageBuilder.addProcessFromXml(PackageBuilder.java:516)
> 	at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:556)
> 	at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:28)
> 	at com.ariadnext.NewDroolsTest$RulesUtils.loadRules(NewDroolsTest.java:107)
> I made a simple junit test which reproduces the bug.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 09:44:23 2011
From: jira-events at lists.jboss.org (Bill Burke (JIRA))
Date: Fri, 8 Jul 2011 09:44:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1231) Horrible XML parsing
	error reports
Message-ID: <51499966.42067.1310132663768.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Horrible XML parsing error reports
----------------------------------

                 Key: AS7-1231
                 URL: https://issues.jboss.org/browse/AS7-1231
             Project: Application Server 7
          Issue Type: Quality Risk
            Reporter: Bill Burke


If I make a typo in jboss-web.xml (or any other descriptor for that matter) I get really obscure errors that don't help me debug the problem.  (See below).  Each project really needs to 

09:39:14,132 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC00001: Failed to start service jboss.deployment.unit."basic.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."basic.war".PARSE: Failed to process phase PARSE of deployment "basic.war"
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
	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_26]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to parse "/content/basic.war/WEB-INF/jboss-web.xml"
	at org.jboss.as.web.deployment.JBossWebParsingDeploymentProcessor.deploy(JBossWebParsingDeploymentProcessor.java:66)
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
	... 5 more
Caused by: com.ctc.wstx.exc.WstxParsingException: Received non-all-whitespace CHARACTERS or CDATA event in nextTag().
 at [row,col {unknown-source}]: [5,4]
	at com.ctc.wstx.sr.StreamScanner.constructWfcException(StreamScanner.java:606)
	at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:479)
	at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:464)
	at com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1137)
	at org.jboss.metadata.parser.jbossweb.ValveMetaDataParser.parse(ValveMetaDataParser.java:45)
	at org.jboss.metadata.parser.jbossweb.JBossWebMetaDataParser.parse(JBossWebMetaDataParser.java:155)
	at org.jboss.as.web.deployment.JBossWebParsingDeploymentProcessor.deploy(JBossWebParsingDeploymentProcessor.java:64)
	... 6 more


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 10:01:23 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Fri, 8 Jul 2011 10:01:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1232)
 :test-connection-in-pool is "useless"
Message-ID: <194589846.42083.1310133683764.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

:test-connection-in-pool is "useless"
-------------------------------------

                 Key: AS7-1232
                 URL: https://issues.jboss.org/browse/AS7-1232
             Project: Application Server 7
          Issue Type: Bug
          Components: JCA
    Affects Versions: 7.0.0.CR1
            Reporter: Heiko Rupp


I have defined a datasource like this:
[domain at localhost:9999 data-source=postresDS] :read-resource
{
    "outcome" => "success",
    "result" => {
        "connection-url" => "jdbc:yadayada",
        "driver-name" => "postgresql-9.0-801.jdbc4.jar",

So obviously with an invalid driver.

But still I get 

[domain at localhost:9999 data-source=postresDS] :test-connection-in-pool
{
    "outcome" => "success",
    "result" => undefined
}

which makes imho no sense.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 10:14:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 8 Jul 2011 10:14:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1233) HornetQ RA gives NPE
 when no activationSpecs are supplied
Message-ID: <1852884591.42102.1310134463614.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

HornetQ RA gives NPE when no activationSpecs are supplied
---------------------------------------------------------

                 Key: AS7-1233
                 URL: https://issues.jboss.org/browse/AS7-1233
             Project: Application Server 7
          Issue Type: Bug
            Reporter: Carlo de Wolf
            Priority: Minor


{noformat}
java.lang.NullPointerException
	at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:882) [:1.6.0_24]
	at org.hornetq.ra.HornetQResourceAdapter.endpointActivation(HornetQResourceAdapter.java:155)
	at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:163)
	at org.jboss.as.ee.component.ComponentStartService.start(ComponentStartService.java:44)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
	... 4 more
{noformat}
It should throw a {{NotSupportedException}}.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 10:36:30 2011
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 8 Jul 2011 10:36:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1234) Hibernate does not
 read/use metadata for orm.xml defined entites
Message-ID: <461439061.42234.1310135790589.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Hibernate does not read/use metadata for orm.xml defined entites
----------------------------------------------------------------

                 Key: AS7-1234
                 URL: https://issues.jboss.org/browse/AS7-1234
             Project: Application Server 7
          Issue Type: Bug
          Components: JPA / Hibernate
    Affects Versions: 7.0.0.CR1, 7.0.0.Beta3, 7.0.0.Final, 7.0.1.Final, 7.1.0.Alpha1
         Environment: windows 7, sql server 2008 r2
            Reporter: Tomaz Cerar
            Assignee: Scott Marlow


I have setup where we have "common" entities defined in global lib/module that application(war/ear) in then dependent on.
Then I declare this entities in orm.xml of my application just by class name.

for instance:
{code:xml}
<entity class="com.company.module.Article"/>
<entity class="com.company.module.Binary"/>
<entity class="com.company.module.Category"/>
{code}

Up until as7/hibernate 4 this worked with no problems, but now it dies with exception "no id defined on entity Article". If I defined id in orm.xml it then finds id field but fails to find anything that is annotated on classes. 
It looks like metadata is not read for this classes and hibernate sees them as just plain pojo with no annotations.
I am guessing that problem has to do something with integration with AS7 that now has jandex index for all annotations...




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 11:03:25 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Fri, 8 Jul 2011 11:03:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1885) Duplicated
 message delivery in closing a connection while a transaction is committing
Message-ID: <230950532.42441.1310137405043.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Duplicated message delivery in closing a connection while a transaction is committing
-------------------------------------------------------------------------------------

                 Key: JBMESSAGING-1885
                 URL: https://issues.jboss.org/browse/JBMESSAGING-1885
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core
    Affects Versions: 1.4.8.SP1, 1.4.0.SP3.CP13
            Reporter: Yong Hao Gao
            Assignee: Yong Hao Gao
             Fix For: 1.4.0.SP3.CP14, 1.4.8.SP2


A message may be delivered twice when the following events happens in order:

1. A client receives a message in a transaction and is committing it. In the meantime the connection is closed (by, for example, user shut down the client application) in another thread.
2. At the server side, the connection closing will cause the message (not prepared) to be cancelled back to queue. In the meantime the committing will remove the message. Both actions are performed concurrently.
3. If the committing happens before the connection closing, transaction commit successfully and message won't get cancelled. But if the committing happens after connection closing, there is a chance the message is cancelled back to queue and  yet the transaction is committed successfully. So the message will be delivered twice.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 11:05:24 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Fri, 8 Jul 2011 11:05:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1885) Duplicated
 message delivery in closing a connection while a transaction is committing
In-Reply-To: <230950532.42441.1310137405043.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1393601279.42469.1310137524158.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao updated JBMESSAGING-1885:
--------------------------------------



> Duplicated message delivery in closing a connection while a transaction is committing
> -------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1885
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1885
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP13, 1.4.8.SP1
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP14, 1.4.8.SP2
>
>
> A message may be delivered twice when the following events happens in order:
> 1. A client receives a message in a transaction and is committing it. In the meantime the connection is closed (by, for example, user shut down the client application) in another thread.
> 2. At the server side, the connection closing will cause the message (not prepared) to be cancelled back to queue. In the meantime the committing will remove the message. Both actions are performed concurrently.
> 3. If the committing happens before the connection closing, transaction commit successfully and message won't get cancelled. But if the committing happens after connection closing, there is a chance the message is cancelled back to queue and  yet the transaction is committed successfully. So the message will be delivered twice.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 11:11:24 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 8 Jul 2011 11:11:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1234) Hibernate does not
 read/use metadata for orm.xml defined entites
In-Reply-To: <461439061.42234.1310135790589.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <920580429.42486.1310137884804.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on AS7-1234:
-----------------------------------

A test case would be helpful. :)

Adding TRACE logging to org.jboss.as.jpa.hibernate.HibernateAnnotationScanner (and related AS7 JPA code) might also be helpful.

It looks like org.hibernate.internal.util.xml.MappingReader already has some DEBUG logging that might be helpful (I'm not sure if that is where we are reading your orm.xml).


> Hibernate does not read/use metadata for orm.xml defined entites
> ----------------------------------------------------------------
>
>                 Key: AS7-1234
>                 URL: https://issues.jboss.org/browse/AS7-1234
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta3, 7.0.0.CR1, 7.0.0.Final, 7.0.1.Final, 7.1.0.Alpha1
>         Environment: windows 7, sql server 2008 r2
>            Reporter: Tomaz Cerar
>            Assignee: Scott Marlow
>
> I have setup where we have "common" entities defined in global lib/module that application(war/ear) in then dependent on.
> Then I declare this entities in orm.xml of my application just by class name.
> for instance:
> {code:xml}
> <entity class="com.company.module.Article"/>
> <entity class="com.company.module.Binary"/>
> <entity class="com.company.module.Category"/>
> {code}
> Up until as7/hibernate 4 this worked with no problems, but now it dies with exception "no id defined on entity Article". If I defined id in orm.xml it then finds id field but fails to find anything that is annotated on classes. 
> It looks like metadata is not read for this classes and hibernate sees them as just plain pojo with no annotations.
> I am guessing that problem has to do something with integration with AS7 that now has jandex index for all annotations...

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 11:17:24 2011
From: jira-events at lists.jboss.org (Colin Mondesir (JIRA))
Date: Fri, 8 Jul 2011 11:17:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1886) After
 clearBody() followed by QueueSession.recover() redelivered message is not
 correct
Message-ID: <1534319128.42505.1310138244136.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

After clearBody() followed by QueueSession.recover() redelivered message is not correct
---------------------------------------------------------------------------------------

                 Key: JBMESSAGING-1886
                 URL: https://issues.jboss.org/browse/JBMESSAGING-1886
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core
    Affects Versions: 1.4.0.SP3.CP13
            Reporter: Colin Mondesir
            Assignee: Yong Hao Gao


After calling clearBody() on a message followed by QueueSession.recover() the re-delivered message does not contain the original body. I've verified this behaviour on EAP 4.3 CP09.

 The spec states:

 ------------------------------------------
 A consumer can modify a received message after calling either the clearBody or
 clearProperties method to make the body or properties writable. If the consumer
 modifies a received message, and the message is subsequently redelivered, the
 redelivered message must be the original, unmodified message
 ------------------------------------------


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 11:28:24 2011
From: jira-events at lists.jboss.org (Jim Tyrrell (JIRA))
Date: Fri, 8 Jul 2011 11:28:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (AS7-1235) Customer Provided
 Spring App that just works on Tomcat should work on JBoss AS 7,
 this JBoss internal and was provided under NDA
Message-ID: <442002665.42547.1310138904116.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jim Tyrrell moved JBPAPP-6796 to AS7-1235:
------------------------------------------

           Project: Application Server 7  (was: JBoss Enterprise Application Platform)
               Key: AS7-1235  (was: JBPAPP-6796)
        Issue Type: Feature Request  (was: Bug)
          Workflow: GIT Pull Request workflow   (was: jira)
          Security:     (was: JBoss Internal)
    Docs QE Status:   (was: NEW)


> Customer Provided Spring App that just works on Tomcat should work on JBoss AS 7, this JBoss internal and was provided under NDA
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1235
>                 URL: https://issues.jboss.org/browse/AS7-1235
>             Project: Application Server 7
>          Issue Type: Feature Request
>         Environment: JBoss AS 7 CR 1
>            Reporter: Jim Tyrrell
>         Attachments: BRMSPoc.war.failed
>
>
> Application that just works on Tomcat7 does not just work on AS 7 CR1.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 11:46:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 8 Jul 2011 11:46:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1234) Hibernate does not
 read/use metadata for orm.xml defined entites
In-Reply-To: <461439061.42234.1310135790589.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1448071840.42649.1310139983955.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on AS7-1234:
-----------------------------------

I'll work on adding a unit test as well (to see if I can recreate the bug).

> Hibernate does not read/use metadata for orm.xml defined entites
> ----------------------------------------------------------------
>
>                 Key: AS7-1234
>                 URL: https://issues.jboss.org/browse/AS7-1234
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta3, 7.0.0.CR1, 7.0.0.Final, 7.0.1.Final, 7.1.0.Alpha1
>         Environment: windows 7, sql server 2008 r2
>            Reporter: Tomaz Cerar
>            Assignee: Scott Marlow
>
> I have setup where we have "common" entities defined in global lib/module that application(war/ear) in then dependent on.
> Then I declare this entities in orm.xml of my application just by class name.
> for instance:
> {code:xml}
> <entity class="com.company.module.Article"/>
> <entity class="com.company.module.Binary"/>
> <entity class="com.company.module.Category"/>
> {code}
> Up until as7/hibernate 4 this worked with no problems, but now it dies with exception "no id defined on entity Article". If I defined id in orm.xml it then finds id field but fails to find anything that is annotated on classes. 
> It looks like metadata is not read for this classes and hibernate sees them as just plain pojo with no annotations.
> I am guessing that problem has to do something with integration with AS7 that now has jandex index for all annotations...

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 12:02:24 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 8 Jul 2011 12:02:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-579) Implement JMS MDB
	integration
In-Reply-To: <373845573.30344.1300298446712.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1209405257.42696.1310140944056.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf commented on AS7-579:
-----------------------------------

{noformat}
org.jboss.jca.core.spi.rar.NotFoundException: IJ000855: hornetq-ra isn't registered
	at org.jboss.jca.core.rar.SimpleResourceAdapterRepository.getMessageListeners(SimpleResourceAdapterRepository.java:263)
	at org.jboss.as.ejb3.component.messagedriven.AbstractEndpointDeployer.getMessageListener(AbstractEndpointDeployer.java:66)
	at org.jboss.as.ejb3.component.messagedriven.AbstractEndpointDeployer.createActivationSpecs(AbstractEndpointDeployer.java:48)
	... 7 more
{noformat}

> Implement JMS MDB integration
> -----------------------------
>
>                 Key: AS7-579
>                 URL: https://issues.jboss.org/browse/AS7-579
>             Project: Application Server 7
>          Issue Type: Sub-task
>            Reporter: David Lloyd
>            Assignee: Carlo de Wolf
>             Fix For: 7.1.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 12:19:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 8 Jul 2011 12:19:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1234) Hibernate does not
 read/use metadata for orm.xml defined entites
In-Reply-To: <461439061.42234.1310135790589.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <648261264.42701.1310141963706.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on AS7-1234:
-----------------------------------

I'm not sure if I have orm.xml bit correct but seem to be recreating the issue.  See https://github.com/scottmarlow/jboss-as/commit/7aa00c5e575110f41b2f6de5aa7106729e7d8aae

server.log (trace not enabled yet) http://pastie.org/2183589

> Hibernate does not read/use metadata for orm.xml defined entites
> ----------------------------------------------------------------
>
>                 Key: AS7-1234
>                 URL: https://issues.jboss.org/browse/AS7-1234
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta3, 7.0.0.CR1, 7.0.0.Final, 7.0.1.Final, 7.1.0.Alpha1
>         Environment: windows 7, sql server 2008 r2
>            Reporter: Tomaz Cerar
>            Assignee: Scott Marlow
>
> I have setup where we have "common" entities defined in global lib/module that application(war/ear) in then dependent on.
> Then I declare this entities in orm.xml of my application just by class name.
> for instance:
> {code:xml}
> <entity class="com.company.module.Article"/>
> <entity class="com.company.module.Binary"/>
> <entity class="com.company.module.Category"/>
> {code}
> Up until as7/hibernate 4 this worked with no problems, but now it dies with exception "no id defined on entity Article". If I defined id in orm.xml it then finds id field but fails to find anything that is annotated on classes. 
> It looks like metadata is not read for this classes and hibernate sees them as just plain pojo with no annotations.
> I am guessing that problem has to do something with integration with AS7 that now has jandex index for all annotations...

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 12:48:24 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 8 Jul 2011 12:48:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1234) Hibernate does not
 read/use metadata for orm.xml defined entites
In-Reply-To: <461439061.42234.1310135790589.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <366898661.42737.1310143704302.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on AS7-1234:
-----------------------------------

Is related to HHH-6159 (http://opensource.atlassian.com/projects/hibernate/browse/HHH-6159)


> Hibernate does not read/use metadata for orm.xml defined entites
> ----------------------------------------------------------------
>
>                 Key: AS7-1234
>                 URL: https://issues.jboss.org/browse/AS7-1234
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta3, 7.0.0.CR1, 7.0.0.Final, 7.0.1.Final, 7.1.0.Alpha1
>         Environment: windows 7, sql server 2008 r2
>            Reporter: Tomaz Cerar
>            Assignee: Scott Marlow
>
> I have setup where we have "common" entities defined in global lib/module that application(war/ear) in then dependent on.
> Then I declare this entities in orm.xml of my application just by class name.
> for instance:
> {code:xml}
> <entity class="com.company.module.Article"/>
> <entity class="com.company.module.Binary"/>
> <entity class="com.company.module.Category"/>
> {code}
> Up until as7/hibernate 4 this worked with no problems, but now it dies with exception "no id defined on entity Article". If I defined id in orm.xml it then finds id field but fails to find anything that is annotated on classes. 
> It looks like metadata is not read for this classes and hibernate sees them as just plain pojo with no annotations.
> I am guessing that problem has to do something with integration with AS7 that now has jandex index for all annotations...

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 12:48:24 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Fri, 8 Jul 2011 12:48:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1214) Using specific
 socket-binding does not override bind address for
 pbcast.STREAMING_STATE_TRANSFER
In-Reply-To: <1342587320.38022.1309976244373.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <188719020.42740.1310143704391.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro resolved AS7-1214.
-------------------------------

    Fix Version/s: 7.0.1.Final
                   7.1.0.Alpha1
       Resolution: Done


> Using specific socket-binding does not override bind address for pbcast.STREAMING_STATE_TRANSFER
> ------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1214
>                 URL: https://issues.jboss.org/browse/AS7-1214
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.CR1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 7.0.1.Final, 7.1.0.Alpha1
>
>
> You should be able to override the bind_addr and bind_port by defining a specific socket-binding, however, this doesn't work.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 12:50:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Fri, 8 Jul 2011 12:50:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1215)
 pbcast.STREAMING_STATE_TRANSFER should default to use the bind address of
 the transport
In-Reply-To: <951060406.38063.1309976723720.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2022231378.42744.1310143823670.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro resolved AS7-1215.
-------------------------------

    Fix Version/s: 7.0.1.Final
                   7.1.0.Alpha1
       Resolution: Done


> pbcast.STREAMING_STATE_TRANSFER should default to use the bind address of the transport
> ---------------------------------------------------------------------------------------
>
>                 Key: AS7-1215
>                 URL: https://issues.jboss.org/browse/AS7-1215
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 7.0.1.Final, 7.1.0.Alpha1
>
>
> Currently, pbcast.STREAMING_STATE_TRANSFER uses an auto-detected bind address, if none was specified.  It should default to the bind address or the transport.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 12:52:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 8 Jul 2011 12:52:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1232)
 :test-connection-in-pool is "useless"
In-Reply-To: <194589846.42083.1310133683764.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <885557632.42751.1310143943652.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen reassigned AS7-1232:
------------------------------------

    Assignee: Stefano Maestri


> :test-connection-in-pool is "useless"
> -------------------------------------
>
>                 Key: AS7-1232
>                 URL: https://issues.jboss.org/browse/AS7-1232
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 7.0.0.CR1
>            Reporter: Heiko Rupp
>            Assignee: Stefano Maestri
>
> I have defined a datasource like this:
> [domain at localhost:9999 data-source=postresDS] :read-resource
> {
>     "outcome" => "success",
>     "result" => {
>         "connection-url" => "jdbc:yadayada",
>         "driver-name" => "postgresql-9.0-801.jdbc4.jar",
> So obviously with an invalid driver.
> But still I get 
> [domain at localhost:9999 data-source=postresDS] :test-connection-in-pool
> {
>     "outcome" => "success",
>     "result" => undefined
> }
> which makes imho no sense.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 13:20:29 2011
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 8 Jul 2011 13:20:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1234) Hibernate does not
 read/use metadata for orm.xml defined entites
In-Reply-To: <461439061.42234.1310135790589.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1267283728.42801.1310145629933.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar commented on AS7-1234:
----------------------------------

hi, this is the exception I get, but in your case it is the proper exception if I am reading your code/commit right.
you don't have any property/field annotated with @Id and that makes exception proper even if you import them??

I wanted to create automated test case but I don't know how to create and register as7 module. other stuff it is not a problem.

If you want I can create sample applications and attach them here.


> Hibernate does not read/use metadata for orm.xml defined entites
> ----------------------------------------------------------------
>
>                 Key: AS7-1234
>                 URL: https://issues.jboss.org/browse/AS7-1234
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta3, 7.0.0.CR1, 7.0.0.Final, 7.0.1.Final, 7.1.0.Alpha1
>         Environment: windows 7, sql server 2008 r2
>            Reporter: Tomaz Cerar
>            Assignee: Scott Marlow
>
> I have setup where we have "common" entities defined in global lib/module that application(war/ear) in then dependent on.
> Then I declare this entities in orm.xml of my application just by class name.
> for instance:
> {code:xml}
> <entity class="com.company.module.Article"/>
> <entity class="com.company.module.Binary"/>
> <entity class="com.company.module.Category"/>
> {code}
> Up until as7/hibernate 4 this worked with no problems, but now it dies with exception "no id defined on entity Article". If I defined id in orm.xml it then finds id field but fails to find anything that is annotated on classes. 
> It looks like metadata is not read for this classes and hibernate sees them as just plain pojo with no annotations.
> I am guessing that problem has to do something with integration with AS7 that now has jandex index for all annotations...

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 13:26:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 8 Jul 2011 13:26:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1234) Hibernate does not
 read/use metadata for orm.xml defined entites
In-Reply-To: <461439061.42234.1310135790589.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <810742573.42809.1310145983669.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on AS7-1234:
-----------------------------------

Hmm, I'll specify the id field info...  

> Hibernate does not read/use metadata for orm.xml defined entites
> ----------------------------------------------------------------
>
>                 Key: AS7-1234
>                 URL: https://issues.jboss.org/browse/AS7-1234
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta3, 7.0.0.CR1, 7.0.0.Final, 7.0.1.Final, 7.1.0.Alpha1
>         Environment: windows 7, sql server 2008 r2
>            Reporter: Tomaz Cerar
>            Assignee: Scott Marlow
>
> I have setup where we have "common" entities defined in global lib/module that application(war/ear) in then dependent on.
> Then I declare this entities in orm.xml of my application just by class name.
> for instance:
> {code:xml}
> <entity class="com.company.module.Article"/>
> <entity class="com.company.module.Binary"/>
> <entity class="com.company.module.Category"/>
> {code}
> Up until as7/hibernate 4 this worked with no problems, but now it dies with exception "no id defined on entity Article". If I defined id in orm.xml it then finds id field but fails to find anything that is annotated on classes. 
> It looks like metadata is not read for this classes and hibernate sees them as just plain pojo with no annotations.
> I am guessing that problem has to do something with integration with AS7 that now has jandex index for all annotations...

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 13:30:24 2011
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Fri, 8 Jul 2011 13:30:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-9336) password_tool.bat
 generates java.lang.ClassNotFoundException
In-Reply-To: <1730826219.32482.1303048593076.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <422167043.42814.1310146224623.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Marcus Moyses resolved JBAS-9336.
---------------------------------

    Resolution: Done


Applied proposed patch

> password_tool.bat generates java.lang.ClassNotFoundException
> ------------------------------------------------------------
>
>                 Key: JBAS-9336
>                 URL: https://issues.jboss.org/browse/JBAS-9336
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: 6.0.0.Final
>         Environment: Windows
>            Reporter: Andrew Murphy
>            Assignee: Marcus Moyses
>             Fix For: 6.1.0
>
>         Attachments: JBAS-9336.patch
>
>
> The password_tool.bat command found in %JBOSS_HOME%\bin generates a java.lang.ClassNotFoundException
> D:\JBoss\jboss-6.0.0.GA\bin>password_tool.bat
> **********************************
> ****  JBoss Password Tool********
> **********************************
> Keystore is null. Please specify keystore below:
> 0: Encrypt Keystore Password 1:Specify KeyStore 2:Create Password  3: Remove a domain 4:Enquire Domain 5:Exit
> 1
> Enter Keystore location including the file name
> password/password.keystore
> Enter Keystore alias
> jboss
> log4j:WARN No appenders could be found for logger (org.apache.xml.security.Init).
> log4j:WARN Please initialize the log4j system properly.
> Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/xml/utils/URI$MalformedURIException
>         at org.jboss.security.integration.password.XMLEncryptionUtil.decrypt(XMLEncryptionUtil.java:205)
>         at org.jboss.security.integration.password.PasswordMaskManagement.load(PasswordMaskManagement.java:200)
>         at org.jboss.security.integration.password.PasswordTool.load(PasswordTool.java:172)
>         at org.jboss.security.integration.password.PasswordTool.main(PasswordTool.java:128)
> Caused by: java.lang.ClassNotFoundException: org.apache.xml.utils.URI$MalformedURIException
>         at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
>         at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
>         ... 4 more
> org.jboss.security.integration.password.PasswordTool$ShutdownHook run called
> Storing domains [
> ]
> Exception in thread "Thread-0" java.lang.NoClassDefFoundError: org/apache/xml/utils/URI$MalformedURIException
>         at org.jboss.security.integration.password.XMLEncryptionUtil.encrypt(XMLEncryptionUtil.java:136)
>         at org.jboss.security.integration.password.PasswordMaskManagement.store(PasswordMaskManagement.java:251)
>         at org.jboss.security.integration.password.PasswordTool$ShutdownHook.run(PasswordTool.java:205)
> Caused by: java.lang.ClassNotFoundException: org.apache.xml.utils.URI$MalformedURIException
>         at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
>         at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
>         ... 3 more
> The underlying problem is xalan.jar cannot be found on the classpath. In GA6.0.0 xalan.jar is located in %JBOSS_HOME%\client, not %JBOSS_HOME%\lib\endorsed, so the password_tool.bat classpath declaration needs to reflect this.
>    

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 14:35:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 8 Jul 2011 14:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1234) Hibernate does not
 read/use metadata for orm.xml defined entites
In-Reply-To: <461439061.42234.1310135790589.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <537804470.42912.1310150123678.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on AS7-1234:
-----------------------------------

I updated the unit test and no longer get the (proper) failure.  I also added more trace logging for the HibernateAnnotationScanner class, to show which classes are found via the AS7 jandex instance.

It would be useful if you attached a sample app that recreates the problem.

> Hibernate does not read/use metadata for orm.xml defined entites
> ----------------------------------------------------------------
>
>                 Key: AS7-1234
>                 URL: https://issues.jboss.org/browse/AS7-1234
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta3, 7.0.0.CR1, 7.0.0.Final, 7.0.1.Final, 7.1.0.Alpha1
>         Environment: windows 7, sql server 2008 r2
>            Reporter: Tomaz Cerar
>            Assignee: Scott Marlow
>
> I have setup where we have "common" entities defined in global lib/module that application(war/ear) in then dependent on.
> Then I declare this entities in orm.xml of my application just by class name.
> for instance:
> {code:xml}
> <entity class="com.company.module.Article"/>
> <entity class="com.company.module.Binary"/>
> <entity class="com.company.module.Category"/>
> {code}
> Up until as7/hibernate 4 this worked with no problems, but now it dies with exception "no id defined on entity Article". If I defined id in orm.xml it then finds id field but fails to find anything that is annotated on classes. 
> It looks like metadata is not read for this classes and hibernate sees them as just plain pojo with no annotations.
> I am guessing that problem has to do something with integration with AS7 that now has jandex index for all annotations...

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 16:05:24 2011
From: jira-events at lists.jboss.org (Jim Tyrrell (JIRA))
Date: Fri, 8 Jul 2011 16:05:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1236) copied lib directory
 in the deployments directory results in deployment
Message-ID: <1720824389.42997.1310155524058.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

copied lib directory in the deployments directory results in deployment 
------------------------------------------------------------------------

                 Key: AS7-1236
                 URL: https://issues.jboss.org/browse/AS7-1236
             Project: Application Server 7
          Issue Type: Feature Request
         Environment: JBoss AS 7 CR 1
            Reporter: Jim Tyrrell


Having an existing zipped up war file, and then unzipping it in the deployment directory, creates a lib directory that has a bunch of jar files in it.  It appears that these jar files in this lib directory are marked as .failed as they are tried to be deployed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 16:07:23 2011
From: jira-events at lists.jboss.org (Jim Crossley (JIRA))
Date: Fri, 8 Jul 2011 16:07:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1237) File-based
 deployments stop working after either a failed attempt or an undeploy
Message-ID: <622871874.43002.1310155643676.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

File-based deployments stop working after either a failed attempt or an undeploy
--------------------------------------------------------------------------------

                 Key: AS7-1237
                 URL: https://issues.jboss.org/browse/AS7-1237
             Project: Application Server 7
          Issue Type: Bug
    Affects Versions: 7.0.0.CR1
            Reporter: Jim Crossley


If I create a new, valid war from scratch and copy it to standalone/deployments, AS7 will deploy it fine.  Further, I can touch it or overwrite it and AS7 will redeploy it.  But once I undeploy it, AS7 will never deploy it again, at least not by my touching it.

Also, if I break it and cause a failed deployment, AS7 will never attempt to redeploy it as a result of my updating it.  Hence, I can't overwrite an invalid war file with a valid one and have it deploy.

To force a deploy, I must either rename my.war.failed to my.war.dodeploy or use the CLI.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 16:07:23 2011
From: jira-events at lists.jboss.org (Jim Tyrrell (JIRA))
Date: Fri, 8 Jul 2011 16:07:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1236) copied lib
 directory in the deployments directory results in deployment
In-Reply-To: <1720824389.42997.1310155524058.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1821852605.43005.1310155643735.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jim Tyrrell commented on AS7-1236:
----------------------------------

Uploading a jar and error messages in a second...

> copied lib directory in the deployments directory results in deployment 
> ------------------------------------------------------------------------
>
>                 Key: AS7-1236
>                 URL: https://issues.jboss.org/browse/AS7-1236
>             Project: Application Server 7
>          Issue Type: Feature Request
>         Environment: JBoss AS 7 CR 1
>            Reporter: Jim Tyrrell
>
> Having an existing zipped up war file, and then unzipping it in the deployment directory, creates a lib directory that has a bunch of jar files in it.  It appears that these jar files in this lib directory are marked as .failed as they are tried to be deployed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 16:21:23 2011
From: jira-events at lists.jboss.org (Jim Tyrrell (JIRA))
Date: Fri, 8 Jul 2011 16:21:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1236) copied lib directory
 in the deployments directory results in deployment
In-Reply-To: <1720824389.42997.1310155524058.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2012813985.43021.1310156483620.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jim Tyrrell updated AS7-1236:
-----------------------------

    Attachment: Sample.war


Sample War file

> copied lib directory in the deployments directory results in deployment 
> ------------------------------------------------------------------------
>
>                 Key: AS7-1236
>                 URL: https://issues.jboss.org/browse/AS7-1236
>             Project: Application Server 7
>          Issue Type: Feature Request
>         Environment: JBoss AS 7 CR 1
>            Reporter: Jim Tyrrell
>         Attachments: Sample.war
>
>
> Having an existing zipped up war file, and then unzipping it in the deployment directory, creates a lib directory that has a bunch of jar files in it.  It appears that these jar files in this lib directory are marked as .failed as they are tried to be deployed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 16:23:23 2011
From: jira-events at lists.jboss.org (Jim Tyrrell (JIRA))
Date: Fri, 8 Jul 2011 16:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1236) copied lib
 directory in the deployments directory results in deployment
In-Reply-To: <1720824389.42997.1310155524058.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1013816378.43024.1310156603708.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jim Tyrrell commented on AS7-1236:
----------------------------------

Put the Sample.war file in the deployments directory of the standalone instance.
Notice the file deploys.
14:18:54,637 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-8) Starting deployment of "Sample.war"
14:18:55,302 INFO  [org.jboss.web] (MSC service thread 1-7) registering web context: /Sample
14:18:55,323 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 2) Deployed "Sample.war"

Now unzip the Sample.war file in the directory, creating a WEB-INF folder in the deployments directory.  You should see the following errors, below.

You will also notice that the jar files are marked as failed.
Jim-Tyrrells-MacBook-Pro-2:deployments jimtyrrell$ ls WEB-INF/lib/
drools-api-5.1.1.jar			drools-core-5.1.1.jar.failed
drools-api-5.1.1.jar.failed		log4j-1.2.16.jar
drools-compiler-5.1.1.jar		log4j-1.2.16.jar.failed
drools-compiler-5.1.1.jar.failed	mvel2-2.0.16.jar
drools-core-5.1.1.jar			mvel2-2.0.16.jar.failed




14:19:05,388 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) Starting deployment of "drools-api-5.1.1.jar"
14:19:05,388 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) Starting deployment of "drools-compiler-5.1.1.jar"
14:19:05,390 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-16) Starting deployment of "drools-core-5.1.1.jar"
14:19:05,396 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) Starting deployment of "log4j-1.2.16.jar"
14:19:05,397 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) Starting deployment of "mvel2-2.0.16.jar"
14:19:05,396 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC00001: Failed to start service jboss.deployment.unit."drools-api-5.1.1.jar".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."drools-api-5.1.1.jar".STRUCTURE: Failed to process phase STRUCTURE of deployment "drools-api-5.1.1.jar"
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
	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: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to mount deployment content
	at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:82)
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
	... 5 more
Caused by: java.io.FileNotFoundException: /Users/jimtyrrell 1/Servers/jboss-7.0.0.CR1/standalone/deployments/drools-api-5.1.1.jar (No such file or directory)
	at java.io.FileInputStream.open(Native Method) [:1.6.0_24]
	at java.io.FileInputStream.<init>(FileInputStream.java:106) [:1.6.0_24]
	at org.jboss.vfs.spi.RootFileSystem.openInputStream(RootFileSystem.java:55)
	at org.jboss.vfs.VirtualFile.openStream(VirtualFile.java:238)
	at org.jboss.vfs.VFS.mountZip(VFS.java:434)
	at org.jboss.as.server.deployment.repository.impl.ServerDeploymentRepositoryImpl.mountDeploymentContent(ServerDeploymentRepositoryImpl.java:75)
	at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:78)
	... 6 more

14:19:05,402 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.deployment.unit."mvel2-2.0.16.jar".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."mvel2-2.0.16.jar".STRUCTURE: Failed to process phase STRUCTURE of deployment "mvel2-2.0.16.jar"
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
	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: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to mount deployment content
	at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:82)
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
	... 5 more
Caused by: java.io.FileNotFoundException: /Users/jimtyrrell 1/Servers/jboss-7.0.0.CR1/standalone/deployments/mvel2-2.0.16.jar (No such file or directory)
	at java.io.FileInputStream.open(Native Method) [:1.6.0_24]
	at java.io.FileInputStream.<init>(FileInputStream.java:106) [:1.6.0_24]
	at org.jboss.vfs.spi.RootFileSystem.openInputStream(RootFileSystem.java:55)
	at org.jboss.vfs.VirtualFile.openStream(VirtualFile.java:238)
	at org.jboss.vfs.VFS.mountZip(VFS.java:434)
	at org.jboss.as.server.deployment.repository.impl.ServerDeploymentRepositoryImpl.mountDeploymentContent(ServerDeploymentRepositoryImpl.java:75)
	at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:78)
	... 6 more

14:19:05,397 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-13) MSC00001: Failed to start service jboss.deployment.unit."drools-core-5.1.1.jar".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."drools-core-5.1.1.jar".STRUCTURE: Failed to process phase STRUCTURE of deployment "drools-core-5.1.1.jar"
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
	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: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to mount deployment content
	at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:82)
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
	... 5 more
Caused by: java.io.FileNotFoundException: /Users/jimtyrrell 1/Servers/jboss-7.0.0.CR1/standalone/deployments/drools-core-5.1.1.jar (No such file or directory)
	at java.io.FileInputStream.open(Native Method) [:1.6.0_24]
	at java.io.FileInputStream.<init>(FileInputStream.java:106) [:1.6.0_24]
	at org.jboss.vfs.spi.RootFileSystem.openInputStream(RootFileSystem.java:55)
	at org.jboss.vfs.VirtualFile.openStream(VirtualFile.java:238)
	at org.jboss.vfs.VFS.mountZip(VFS.java:434)
	at org.jboss.as.server.deployment.repository.impl.ServerDeploymentRepositoryImpl.mountDeploymentContent(ServerDeploymentRepositoryImpl.java:75)
	at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:78)
	... 6 more

14:19:05,400 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC00001: Failed to start service jboss.deployment.unit."log4j-1.2.16.jar".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."log4j-1.2.16.jar".STRUCTURE: Failed to process phase STRUCTURE of deployment "log4j-1.2.16.jar"
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
	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: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to mount deployment content
	at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:82)
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
	... 5 more
Caused by: java.io.FileNotFoundException: /Users/jimtyrrell 1/Servers/jboss-7.0.0.CR1/standalone/deployments/log4j-1.2.16.jar (No such file or directory)
	at java.io.FileInputStream.open(Native Method) [:1.6.0_24]
	at java.io.FileInputStream.<init>(FileInputStream.java:106) [:1.6.0_24]
	at org.jboss.vfs.spi.RootFileSystem.openInputStream(RootFileSystem.java:55)
	at org.jboss.vfs.VirtualFile.openStream(VirtualFile.java:238)
	at org.jboss.vfs.VFS.mountZip(VFS.java:434)
	at org.jboss.as.server.deployment.repository.impl.ServerDeploymentRepositoryImpl.mountDeploymentContent(ServerDeploymentRepositoryImpl.java:75)
	at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:78)
	... 6 more

14:19:05,396 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-12) MSC00001: Failed to start service jboss.deployment.unit."drools-compiler-5.1.1.jar".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."drools-compiler-5.1.1.jar".STRUCTURE: Failed to process phase STRUCTURE of deployment "drools-compiler-5.1.1.jar"
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
	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: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to mount deployment content
	at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:82)
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
	... 5 more
Caused by: java.io.FileNotFoundException: /Users/jimtyrrell 1/Servers/jboss-7.0.0.CR1/standalone/deployments/drools-compiler-5.1.1.jar (No such file or directory)
	at java.io.FileInputStream.open(Native Method) [:1.6.0_24]
	at java.io.FileInputStream.<init>(FileInputStream.java:106) [:1.6.0_24]
	at org.jboss.vfs.spi.RootFileSystem.openInputStream(RootFileSystem.java:55)
	at org.jboss.vfs.VirtualFile.openStream(VirtualFile.java:238)
	at org.jboss.vfs.VFS.mountZip(VFS.java:434)
	at org.jboss.as.server.deployment.repository.impl.ServerDeploymentRepositoryImpl.mountDeploymentContent(ServerDeploymentRepositoryImpl.java:75)
	at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:78)
	... 6 more

14:19:05,407 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 1) Deployment of "mvel2-2.0.16.jar" was rolled back with no failure message
14:19:05,407 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 1) Deployment of "log4j-1.2.16.jar" was rolled back with no failure message
14:19:05,408 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 1) Deployment of "drools-core-5.1.1.jar" was rolled back with no failure message
14:19:05,408 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 1) Deployment of "drools-compiler-5.1.1.jar" was rolled back with no failure message
14:19:05,409 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 1) Deployment of "drools-api-5.1.1.jar" was rolled back with failure message {"Failed services" => {"jboss.deployment.unit.\"drools-api-5.1.1.jar\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"drools-api-5.1.1.jar\".STRUCTURE: Failed to process phase STRUCTURE of deployment \"drools-api-5.1.1.jar\""}}
14:19:05,411 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-9) Stopped deployment drools-compiler-5.1.1.jar in 2ms
14:19:05,411 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-14) Stopped deployment log4j-1.2.16.jar in 3ms
14:19:05,411 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-11) Stopped deployment drools-core-5.1.1.jar in 2ms
14:19:05,411 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) Stopped deployment mvel2-2.0.16.jar in 2ms
14:19:05,411 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) Stopped deployment drools-api-5.1.1.jar in 1ms
14:19:05,417 ERROR [org.jboss.as.deployment] (DeploymentScanner-threads - 2) {"Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => {"Failed services" => {"jboss.deployment.unit.\"drools-api-5.1.1.jar\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"drools-api-5.1.1.jar\".STRUCTURE: Failed to process phase STRUCTURE of deployment \"drools-api-5.1.1.jar\""}}}}
14:19:05,418 ERROR [org.jboss.as.deployment] (DeploymentScanner-threads - 2) Composite operation was rolled back
14:19:05,418 ERROR [org.jboss.as.deployment] (DeploymentScanner-threads - 2) Composite operation was rolled back
14:19:05,419 ERROR [org.jboss.as.deployment] (DeploymentScanner-threads - 2) Composite operation was rolled back
14:19:05,419 ERROR [org.jboss.as.deployment] (DeploymentScanner-threads - 2) Composite operation was rolled back
ld

> copied lib directory in the deployments directory results in deployment 
> ------------------------------------------------------------------------
>
>                 Key: AS7-1236
>                 URL: https://issues.jboss.org/browse/AS7-1236
>             Project: Application Server 7
>          Issue Type: Feature Request
>         Environment: JBoss AS 7 CR 1
>            Reporter: Jim Tyrrell
>         Attachments: Sample.war
>
>
> Having an existing zipped up war file, and then unzipping it in the deployment directory, creates a lib directory that has a bunch of jar files in it.  It appears that these jar files in this lib directory are marked as .failed as they are tried to be deployed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 16:57:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 8 Jul 2011 16:57:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1236) copied lib
 directory in the deployments directory results in deployment
In-Reply-To: <1720824389.42997.1310155524058.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <249567187.43034.1310158643648.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on AS7-1236:
---------------------------------------

It is legal to include non-deployment subdirectories under deployments/ as a means of organizing content for whatever purpose the user may have. If the scanner finds a directory whose name does not end in .ear, .jar, .rar, .sar or .war it assumes that directory is just for organizational purposes and will recurse into it looking for deployments. That is what is happening here. Unzipping an archive such that WEB-INF is a directory not under another directory named X.war is a user error.

The scanner can handle this a bit more gracefully by checking for a directory named WEB-INF or META-INF and if found logging a ERROR message and not recursing into it looking for deployments. I'll add that in response to this JIRA. If you unzip an ear this way though, you'll get an ERROR message about the META-INF dir, but it's going to go ahead and try and deploy the modules in the ear since they are not located under META-INF.

> copied lib directory in the deployments directory results in deployment 
> ------------------------------------------------------------------------
>
>                 Key: AS7-1236
>                 URL: https://issues.jboss.org/browse/AS7-1236
>             Project: Application Server 7
>          Issue Type: Feature Request
>         Environment: JBoss AS 7 CR 1
>            Reporter: Jim Tyrrell
>         Attachments: Sample.war
>
>
> Having an existing zipped up war file, and then unzipping it in the deployment directory, creates a lib directory that has a bunch of jar files in it.  It appears that these jar files in this lib directory are marked as .failed as they are tried to be deployed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 17:04:23 2011
From: jira-events at lists.jboss.org (Jim Tyrrell (JIRA))
Date: Fri, 8 Jul 2011 17:04:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1236) copied lib
 directory in the deployments directory results in deployment
In-Reply-To: <1720824389.42997.1310155524058.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2071394986.43075.1310159063684.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jim Tyrrell commented on AS7-1236:
----------------------------------

What about the marking of the jar files as *.failed?  Is that correct behavior?

> copied lib directory in the deployments directory results in deployment 
> ------------------------------------------------------------------------
>
>                 Key: AS7-1236
>                 URL: https://issues.jboss.org/browse/AS7-1236
>             Project: Application Server 7
>          Issue Type: Feature Request
>         Environment: JBoss AS 7 CR 1
>            Reporter: Jim Tyrrell
>         Attachments: Sample.war
>
>
> Having an existing zipped up war file, and then unzipping it in the deployment directory, creates a lib directory that has a bunch of jar files in it.  It appears that these jar files in this lib directory are marked as .failed as they are tried to be deployed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 17:08:23 2011
From: jira-events at lists.jboss.org (Jim Tyrrell (JIRA))
Date: Fri, 8 Jul 2011 17:08:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1236) copied lib
 directory in the deployments directory results in deployment
In-Reply-To: <1720824389.42997.1310155524058.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <41178734.43079.1310159303640.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jim Tyrrell commented on AS7-1236:
----------------------------------

Remember also that the reason I found this was that I had a zipped up war file, and needed to make some changes to it, so I unzipped it locally to create an exploded archive to play with.  While this may be user error, this is not the first time in my development life I have done something like this to work on something...and I am guessing with millions of downloads I am no the only unique one to do this. 

> copied lib directory in the deployments directory results in deployment 
> ------------------------------------------------------------------------
>
>                 Key: AS7-1236
>                 URL: https://issues.jboss.org/browse/AS7-1236
>             Project: Application Server 7
>          Issue Type: Feature Request
>         Environment: JBoss AS 7 CR 1
>            Reporter: Jim Tyrrell
>         Attachments: Sample.war
>
>
> Having an existing zipped up war file, and then unzipping it in the deployment directory, creates a lib directory that has a bunch of jar files in it.  It appears that these jar files in this lib directory are marked as .failed as they are tried to be deployed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 17:28:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 8 Jul 2011 17:28:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1236) Hitting self in head
 with hammer results in headache (was: copied lib directory in the
 deployments directory results in deployment)
In-Reply-To: <1720824389.42997.1310155524058.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <741694213.43091.1310160503631.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd updated AS7-1236:
-----------------------------

    Summary: Hitting self in head with hammer results in headache (was: copied lib directory in the deployments directory results in deployment)  (was: copied lib directory in the deployments directory results in deployment )


> Hitting self in head with hammer results in headache (was: copied lib directory in the deployments directory results in deployment)
> -----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1236
>                 URL: https://issues.jboss.org/browse/AS7-1236
>             Project: Application Server 7
>          Issue Type: Feature Request
>         Environment: JBoss AS 7 CR 1
>            Reporter: Jim Tyrrell
>         Attachments: Sample.war
>
>
> Having an existing zipped up war file, and then unzipping it in the deployment directory, creates a lib directory that has a bunch of jar files in it.  It appears that these jar files in this lib directory are marked as .failed as they are tried to be deployed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 17:30:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 8 Jul 2011 17:30:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1236) copied lib directory
 in the deployments directory results in deployment
In-Reply-To: <1720824389.42997.1310155524058.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <957449814.43096.1310160623656.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd updated AS7-1236:
-----------------------------

    Summary: copied lib directory in the deployments directory results in deployment  (was: Hitting self in head with hammer results in headache (was: copied lib directory in the deployments directory results in deployment))


Ha, ha.

> copied lib directory in the deployments directory results in deployment
> -----------------------------------------------------------------------
>
>                 Key: AS7-1236
>                 URL: https://issues.jboss.org/browse/AS7-1236
>             Project: Application Server 7
>          Issue Type: Feature Request
>         Environment: JBoss AS 7 CR 1
>            Reporter: Jim Tyrrell
>         Attachments: Sample.war
>
>
> Having an existing zipped up war file, and then unzipping it in the deployment directory, creates a lib directory that has a bunch of jar files in it.  It appears that these jar files in this lib directory are marked as .failed as they are tried to be deployed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 18:00:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 8 Jul 2011 18:00:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1236) copied lib directory
 in the deployments directory results in deployment
In-Reply-To: <1720824389.42997.1310155524058.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <292143866.43112.1310162424231.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry resolved AS7-1236.
-----------------------------------

         Assignee: Brian Stansberry
    Fix Version/s: 7.0.1.Final
       Resolution: Done


Resolved via commit http://github.com/jbossas/jboss-as/compare/664ec1d...4514477

Agreed that this is a mistake that people will make. So, the scanner now detects META-INF and WEB-INF directories and will not recurse into them looking for deployments; instead an ERROR is logged. This will prevent incorrect deployments being attempted in many, but not all, cases and for cases where an incorrect deployment is attempted, the log message hopefully will help the user to understand what went wrong.

Re: the .failed markers, yes, if the scanner finds something and tries to deploy it and that fails, the .failed marker is the correct behavior.

> copied lib directory in the deployments directory results in deployment
> -----------------------------------------------------------------------
>
>                 Key: AS7-1236
>                 URL: https://issues.jboss.org/browse/AS7-1236
>             Project: Application Server 7
>          Issue Type: Feature Request
>         Environment: JBoss AS 7 CR 1
>            Reporter: Jim Tyrrell
>            Assignee: Brian Stansberry
>             Fix For: 7.0.1.Final
>
>         Attachments: Sample.war
>
>
> Having an existing zipped up war file, and then unzipping it in the deployment directory, creates a lib directory that has a bunch of jar files in it.  It appears that these jar files in this lib directory are marked as .failed as they are tried to be deployed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul  8 22:08:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 8 Jul 2011 22:08:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1227) AJP 1.3 Connector not
	working
In-Reply-To: <384303877.40850.1310085743612.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1970419887.43200.1310177303627.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-1227:
----------------------------------

    Component/s: Web
                     (was: Web Services)


> AJP 1.3 Connector not working
> -----------------------------
>
>                 Key: AS7-1227
>                 URL: https://issues.jboss.org/browse/AS7-1227
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.CR1
>         Environment: Windows 7 x64
>            Reporter: Gerry Matte
>
> I have been using Apache with Jboss 6 and the mod_jk connector.  When I attempted to configure Jboss 7 to support the same Apache connector, I followed the directions at https://docs.jboss.org/author/display/AS7/Apache+httpd .
> After making the changes, jboss started with no errors.
> When I attempted to use http://localhost/jbossTests rather than http://localhost:8080/jbossTests I was presented with a blank screen and no error messages in either the console window or the server.log file..

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul  9 00:02:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 9 Jul 2011 00:02:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1234) Hibernate does not
 read/use metadata for orm.xml defined entites
In-Reply-To: <461439061.42234.1310135790589.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <713826627.43214.1310184143796.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on AS7-1234:
-----------------------------------

Scott, Tomaz appears to be creating a "module" out of the entity jar and placing it in the JBOSS_HOME/modules location and referencing it via the "Dependencies" in the MANIFEST.MF. We, by default, don't create indexes for the modules. There was a similar issue here AS7-944. 

Tomaz, you'll first have to build a index for the "module" of your entity jar using the Jandex Ant task (https://issues.jboss.org/browse/AS7-944?focusedCommentId=12609000&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12609000). Give it a try and let us know if it works. I'm not sure if Stuart pushed his commits to upstream.


> Hibernate does not read/use metadata for orm.xml defined entites
> ----------------------------------------------------------------
>
>                 Key: AS7-1234
>                 URL: https://issues.jboss.org/browse/AS7-1234
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta3, 7.0.0.CR1, 7.0.0.Final, 7.0.1.Final, 7.1.0.Alpha1
>         Environment: windows 7, sql server 2008 r2
>            Reporter: Tomaz Cerar
>            Assignee: Scott Marlow
>
> I have setup where we have "common" entities defined in global lib/module that application(war/ear) in then dependent on.
> Then I declare this entities in orm.xml of my application just by class name.
> for instance:
> {code:xml}
> <entity class="com.company.module.Article"/>
> <entity class="com.company.module.Binary"/>
> <entity class="com.company.module.Category"/>
> {code}
> Up until as7/hibernate 4 this worked with no problems, but now it dies with exception "no id defined on entity Article". If I defined id in orm.xml it then finds id field but fails to find anything that is annotated on classes. 
> It looks like metadata is not read for this classes and hibernate sees them as just plain pojo with no annotations.
> I am guessing that problem has to do something with integration with AS7 that now has jandex index for all annotations...

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul  9 03:49:23 2011
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Sat, 9 Jul 2011 03:49:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1238) only commands for the
 available subsystems should be available
Message-ID: <722543698.43236.1310197763622.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

only commands for the available subsystems should be available
--------------------------------------------------------------

                 Key: AS7-1238
                 URL: https://issues.jboss.org/browse/AS7-1238
             Project: Application Server 7
          Issue Type: Task
          Components: CLI
    Affects Versions: 7.0.0.CR1
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: 7.0.1.Final


(1) I start the standalone mode with the standard standalone.xml (i.e 
web profile no messaging etc.)

(2) I connect to server using jboss-admin.

(3) I type help on jboss-admin console and get to see commands like 
add-jms-topic etc.

(4) try executing add-jms-queue command and get the error : "No handler ..." since the jms subsystem isn't available in the current configuration.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul  9 09:11:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 9 Jul 2011 09:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1239) Don't WARN about
 files in WEB-INF/classes/META-INF
Message-ID: <142070805.43285.1310217083745.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Don't WARN about files in WEB-INF/classes/META-INF
--------------------------------------------------

                 Key: AS7-1239
                 URL: https://issues.jboss.org/browse/AS7-1239
             Project: Application Server 7
          Issue Type: Task
          Components: EE
    Affects Versions: 7.0.0.CR1
            Reporter: jaikiran pai
            Assignee: jaikiran pai


Currently we log a WARN message if we find any files, other than persistence.xml, in .war/WEB-INF/classes/META-INF folder. We need to get rid of the WARN since Weld looks for beans.xml in that location, although CDI doesn't mandate it, but as per the folks on seam-dev mailing list, all application servers look for beans.xml in this location (including previous version on AS). From what I understand, even AS7 looks for beans.xml in this location currently. So this WARN message is misleading and unnecessary. Let's just allow the individual techs to pick up files from this location, as they wish and get rid of this WARN.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul  9 09:11:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 9 Jul 2011 09:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1239) Don't WARN about
 files in WEB-INF/classes/META-INF
In-Reply-To: <142070805.43285.1310217083745.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2101798829.43287.1310217083835.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on AS7-1239:
-----------------------------------

IRC discussion:

{quote}
[10:31:40] <Jaikiran> stuartdouglas: on a different unrelated note, did you happen to see a thread on seam-dev about a seam config issue in AS 7 CR1?
[10:32:08] <Jaikiran> it later turned out to be a discussion on the support for WEB-INF/classes/META-INF as a metadata location for beans.xml
[10:33:10] <stuartdouglas> looking now
[10:33:34] <stuartdouglas> actually I did read that one
[10:34:09] <Jaikiran> currently we log a WARN for any files other than persistence.xml in that location and I guess we ignore beans.xml in that location during parsing too
[10:34:34] <stuartdouglas> I wonder if I do in the beans.xml processor...
[10:34:58] <stuartdouglas> ah, I do
[10:35:27] <Jaikiran> i think we should just get rid of that WARN message altogether
[10:35:56] <stuartdouglas> It was David that originally wanted us to ignore WEB-INF/classes/META-INF
[10:36:47] <Jaikiran> it's now 1 spec (JPA) + CDI (to be more compatible with other servers) which reads metadata from this location, so i think that WARN will no longer be appropriate
[10:36:47] <stuartdouglas> by getting rid of the warn do you mean stop ignoring META-INF?
[10:37:00] <stuartdouglas> CDI doesn't though
[10:37:08] <Jaikiran> i mean, let whichever tech wants to find files there, find them
[10:37:20] <stuartdouglas> I am fine with that
[10:37:30] <stuartdouglas> but you will have to talk to dmlloyd
[10:37:39] <Jaikiran> dmlloyd: ^ when you are up
[10:38:41] <Jaikiran> dmlloyd: here's the thread for reference http://lists.jboss.org/pipermail/seam-dev/2011-July/003953.html
....
[15:53:45] <dmlloyd> incorrect, I don't actually care one way or another about WEB-INF/classes/META-INF
[15:54:18] <dmlloyd> also: good morning!
...
[16:03:29] <Jaikiran> dmlloyd: ok, i'll get rid of that WARN then
{quote}

> Don't WARN about files in WEB-INF/classes/META-INF
> --------------------------------------------------
>
>                 Key: AS7-1239
>                 URL: https://issues.jboss.org/browse/AS7-1239
>             Project: Application Server 7
>          Issue Type: Task
>          Components: EE
>    Affects Versions: 7.0.0.CR1
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> Currently we log a WARN message if we find any files, other than persistence.xml, in .war/WEB-INF/classes/META-INF folder. We need to get rid of the WARN since Weld looks for beans.xml in that location, although CDI doesn't mandate it, but as per the folks on seam-dev mailing list, all application servers look for beans.xml in this location (including previous version on AS). From what I understand, even AS7 looks for beans.xml in this location currently. So this WARN message is misleading and unnecessary. Let's just allow the individual techs to pick up files from this location, as they wish and get rid of this WARN.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul  9 09:11:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 9 Jul 2011 09:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1239) Don't WARN about
 files in WEB-INF/classes/META-INF
In-Reply-To: <142070805.43285.1310217083745.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2037421906.43290.1310217083950.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai updated AS7-1239:
------------------------------

    Forum Reference: http://lists.jboss.org/pipermail/seam-dev/2011-July/003953.html


> Don't WARN about files in WEB-INF/classes/META-INF
> --------------------------------------------------
>
>                 Key: AS7-1239
>                 URL: https://issues.jboss.org/browse/AS7-1239
>             Project: Application Server 7
>          Issue Type: Task
>          Components: EE
>    Affects Versions: 7.0.0.CR1
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> Currently we log a WARN message if we find any files, other than persistence.xml, in .war/WEB-INF/classes/META-INF folder. We need to get rid of the WARN since Weld looks for beans.xml in that location, although CDI doesn't mandate it, but as per the folks on seam-dev mailing list, all application servers look for beans.xml in this location (including previous version on AS). From what I understand, even AS7 looks for beans.xml in this location currently. So this WARN message is misleading and unnecessary. Let's just allow the individual techs to pick up files from this location, as they wish and get rid of this WARN.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul  9 09:31:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sat, 9 Jul 2011 09:31:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1240) Allow FS deployment
 scanner to treat deleting deployment content as a trigger for undeploy
Message-ID: <1052869189.43293.1310218283650.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Allow FS deployment scanner to treat deleting deployment content as a trigger for undeploy
------------------------------------------------------------------------------------------

                 Key: AS7-1240
                 URL: https://issues.jboss.org/browse/AS7-1240
             Project: Application Server 7
          Issue Type: Feature Request
          Components: Server
    Affects Versions: 7.0.0.CR1
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 7.0.1.Final


Currently you have to delete the .deployed file to trigger an undeploy. FileSystemDeploymentService should also treat deleting the deployment content as a trigger.

Deleting the content *is the incorrect way to trigger undeployment of an exploded archive.*  It's perfectly fine for a zipped deployment, but for an exploded deployment it removes the content out from under the appserver before the AS has a chance to properly undeploy.

Still, even though deleting the content as a trigger is the wrong thing to do in the exploded case, it's the more intuitive thing to do in the non-exploded case, and having the AS use it as a trigger in the exploded case doesn't increase the harm. The content is gone; the app is broken, might as well try and undeploy it.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul  9 16:28:23 2011
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Sat, 9 Jul 2011 16:28:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1241) Async logger without
 subhandler prevents server startup
Message-ID: <1128401256.43344.1310243303692.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Async logger without subhandler prevents server startup
-------------------------------------------------------

                 Key: AS7-1241
                 URL: https://issues.jboss.org/browse/AS7-1241
             Project: Application Server 7
          Issue Type: Bug
          Components: Logging
    Affects Versions: 7.1.0.Alpha1
            Reporter: Stan Silvert


<async-handler name="ASYNC">
   <level name="INFO"/>
   <queue-length value="1024"/>
   <overflow-action value="BLOCK"/> 
   <subhandlers>
   </subhandlers>               
</async-handler>

16:26:01,926 ERROR [org.jboss.as.controller] Operation ("add") failed - address: ([
    ("subsystem" => "logging"),
    ("async-handler" => "ASYNC")
]): java.lang.IllegalArgumentException
        at org.jboss.dmr.ModelValue.asList(ModelValue.java:128)
        at org.jboss.dmr.ModelNode.asList(ModelNode.java:1096)
        at org.jboss.as.logging.AsyncHandlerAdd.performRuntime(AsyncHandlerAdd.java:67)
        at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:47)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:53)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:53)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:53)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:53)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:53)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.server.DeployerChainAddHandler.execute(DeployerChainAddHandler.java:105)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.txn.TransactionSubsystemAdd.execute(TransactionSubsystemAdd.java:272)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.security.SecuritySubsystemAdd.execute(SecuritySubsystemAdd.java:300)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.threads.BoundedQueueThreadPoolAdd.execute(BoundedQueueThreadPoolAdd.java:133)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.threads.BoundedQueueThreadPoolAdd.execute(BoundedQueueThreadPoolAdd.java:133)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.logging.RootLoggerAdd.execute(RootLoggerAdd.java:94)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.operations.global.WriteAttributeHandlers$WriteAttributeOperationHandler.modelChanged(WriteAttributeHandlers.java:114)
        at org.jboss.as.controller.operations.global.WriteAttributeHandlers$WriteAttributeOperationHandler.execute(WriteAttributeHandlers.java:81)
        at org.jboss.as.controller.operations.global.GlobalOperationHandlers$WriteAttributeHandler.execute(GlobalOperationHandlers.java:395)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
        at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
        at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
        at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
        at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:143)
        at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:109)
        at org.jboss.as.server.ServerService.boot(ServerService.java:204)
        at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:104)
        at org.jboss.as.server.ServerService.boot(ServerService.java:193)
        at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:83)
        at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]

16:26:02,236 INFO  [org.jboss.as.controller] Service status report
   New missing/unsatisfied dependencies:
      service jboss.network.management (missing)
      service jboss.remoting.endpoint (missing)

16:26:02,249 INFO  [org.jboss.as.controller] Service status report
   Newly corrected services:
      service jboss.network.management (no longer required)
      service jboss.remoting.endpoint (no longer required)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul  9 16:30:23 2011
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Sat, 9 Jul 2011 16:30:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1241) Async logger without
 subhandler prevents server startup
In-Reply-To: <1128401256.43344.1310243303692.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1326640188.43350.1310243423661.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stan Silvert reassigned AS7-1241:
---------------------------------

    Assignee: David Lloyd


> Async logger without subhandler prevents server startup
> -------------------------------------------------------
>
>                 Key: AS7-1241
>                 URL: https://issues.jboss.org/browse/AS7-1241
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.1.0.Alpha1
>            Reporter: Stan Silvert
>            Assignee: David Lloyd
>
> <async-handler name="ASYNC">
>    <level name="INFO"/>
>    <queue-length value="1024"/>
>    <overflow-action value="BLOCK"/> 
>    <subhandlers>
>    </subhandlers>               
> </async-handler>
> 16:26:01,926 ERROR [org.jboss.as.controller] Operation ("add") failed - address: ([
>     ("subsystem" => "logging"),
>     ("async-handler" => "ASYNC")
> ]): java.lang.IllegalArgumentException
>         at org.jboss.dmr.ModelValue.asList(ModelValue.java:128)
>         at org.jboss.dmr.ModelNode.asList(ModelNode.java:1096)
>         at org.jboss.as.logging.AsyncHandlerAdd.performRuntime(AsyncHandlerAdd.java:67)
>         at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:47)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:53)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:53)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:53)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:53)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:53)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.server.DeployerChainAddHandler.execute(DeployerChainAddHandler.java:105)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.txn.TransactionSubsystemAdd.execute(TransactionSubsystemAdd.java:272)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.security.SecuritySubsystemAdd.execute(SecuritySubsystemAdd.java:300)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.threads.BoundedQueueThreadPoolAdd.execute(BoundedQueueThreadPoolAdd.java:133)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.threads.BoundedQueueThreadPoolAdd.execute(BoundedQueueThreadPoolAdd.java:133)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.logging.RootLoggerAdd.execute(RootLoggerAdd.java:94)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.operations.global.WriteAttributeHandlers$WriteAttributeOperationHandler.modelChanged(WriteAttributeHandlers.java:114)
>         at org.jboss.as.controller.operations.global.WriteAttributeHandlers$WriteAttributeOperationHandler.execute(WriteAttributeHandlers.java:81)
>         at org.jboss.as.controller.operations.global.GlobalOperationHandlers$WriteAttributeHandler.execute(GlobalOperationHandlers.java:395)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:143)
>         at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:109)
>         at org.jboss.as.server.ServerService.boot(ServerService.java:204)
>         at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:104)
>         at org.jboss.as.server.ServerService.boot(ServerService.java:193)
>         at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:83)
>         at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]
> 16:26:02,236 INFO  [org.jboss.as.controller] Service status report
>    New missing/unsatisfied dependencies:
>       service jboss.network.management (missing)
>       service jboss.remoting.endpoint (missing)
> 16:26:02,249 INFO  [org.jboss.as.controller] Service status report
>    Newly corrected services:
>       service jboss.network.management (no longer required)
>       service jboss.remoting.endpoint (no longer required)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul  9 19:23:23 2011
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 9 Jul 2011 19:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2730) Duplicate rules
 name errors not being identified across multiple resources in same package
In-Reply-To: <486635734.27907.1286821623782.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1638527760.43361.1310253803752.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Mark Proctor commented on JBRULES-2730:
---------------------------------------

Rule replacement is allowed and an important part of a dynamic rule engine. I believe what we do is disallow it from the same resource (should double check that) i.e. a drl that repeats the rule twice is an error. If you load a later resource it will overwrite the previous.

> Duplicate rules name errors not being identified across multiple resources in same package
> ------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2730
>                 URL: https://issues.jboss.org/browse/JBRULES-2730
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Windows XP, Java 1.6.0_17
>            Reporter: Michael Pellegrini
>            Assignee: Mark Proctor
>              Labels: drl, duplicate, expert, rule
>
> The validateUniqueRuleNamesmethod in the org.drools.compiler.PackageBuilder class currently only checks for duplicate rule names that are defined within the same resource.  However, in the case where there are multiple resources added to the knowledge builder that share the same package name then the validateUniqueRuleNames method is not detecting duplicates across the package.
> In cases where rules have the same name and are defined in the same package then I would have expected to get a duplicate rule error but I do not as the rules are physically reside in two separate resources.
> It seems logical that in addition to checking if any rules are duplicated within the resource that it also checks to see that rule was already defined in the package registry as well.  Otherwise the last rule overwrites the first and creates some rather odd behavior.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul  9 19:25:23 2011
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 9 Jul 2011 19:25:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3063) Drools should
 not allow set two rules with the same name for the same package
Message-ID: <1943839032.43366.1310253923736.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Mark Proctor commented on JBRULES-3063:
---------------------------------------

Rule replacement is allowed and an important part of a dynamic rule engine. I believe what we do is disallow it from the same resource (should double check that) i.e. a drl that repeats the rule twice is an error. If you load a later resource it will overwrite the previous.

Thinking about this some more. We should probably add a "getWarnings" as well as getErrors. Rule overwriting would come with a warning.

We might even find a way build warning filters, a composite set of warnings to fail on, but user defineable.

> Drools should not allow set two rules with the same name for the same package
> -----------------------------------------------------------------------------
>
>                 Key: JBRULES-3063
>                 URL: https://issues.jboss.org/browse/JBRULES-3063
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler
>    Affects Versions: 5.1.1.FINAL
>            Reporter: Alessandro Lazarotti
>            Assignee: Tihomir Surdilovic
>            Priority: Minor
>             Fix For: FUTURE
>
>
> Drools should not allow set two rules with the same name for the same package
> As expected, Drools does not allow us to define two rules with the same name in a same DRL file.
> But if there are two rules with the same name, in the same package, but in separate files, no exception or warning is issued, just one rule overrides the other in silence.
> From documentation:
> "A rule must have a name, unique within its rule package. If a rule is defined twice in a single DRL, an error will appear when one loads it. If a DRL that includes a rule name already in the package is added, the previous rule is repalced."[1]
> [1] http://docs.redhat.com/docs/en-US/JBoss_Enterprise_SOA_Platform/5/html/JBoss_Rules_5_Reference_Guide/chap-language_reference.html#sect-rule
> Different behavior for a similar action is not good. Both should alert user about a rule name repeated.
> For large projects using a lot of DRL files can be hard to track mistakes occurred by rules override . It is really necessary provide an ERROR message for this.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul  9 19:27:23 2011
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 9 Jul 2011 19:27:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-2221) duplicate
 function in different .drl files of same package silently overridden
In-Reply-To: <122753373.1248971669312.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2111894098.43370.1310254043758.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Mark Proctor resolved JBRULES-2221.
-----------------------------------

    Fix Version/s: 5.3.0.Beta1
       Resolution: Duplicate Issue


> duplicate function in different .drl files of same package silently overridden
> ------------------------------------------------------------------------------
>
>                 Key: JBRULES-2221
>                 URL: https://issues.jboss.org/browse/JBRULES-2221
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler (expert)
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Wolfgang Laun
>            Assignee: Mark Proctor
>             Fix For: 5.3.0.Beta1
>
>
> Given package p and .drl files a.drl and b.drl, both in this package.
> If a.drl contains a function foo and b.drl a function foo, then b's function will silently supercede a's function, or vice versa. There is no indication of an error in the return value of kBuilder.getErrors().

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul  9 19:29:23 2011
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Sat, 9 Jul 2011 19:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-2730) Duplicate rules
 name errors not being identified across multiple resources in same package
In-Reply-To: <486635734.27907.1286821623782.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1971649902.43374.1310254163682.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Mark Proctor resolved JBRULES-2730.
-----------------------------------

    Fix Version/s: 5.3.0.Beta1
       Resolution: Duplicate Issue


> Duplicate rules name errors not being identified across multiple resources in same package
> ------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2730
>                 URL: https://issues.jboss.org/browse/JBRULES-2730
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Windows XP, Java 1.6.0_17
>            Reporter: Michael Pellegrini
>            Assignee: Mark Proctor
>              Labels: drl, duplicate, expert, rule
>             Fix For: 5.3.0.Beta1
>
>
> The validateUniqueRuleNamesmethod in the org.drools.compiler.PackageBuilder class currently only checks for duplicate rule names that are defined within the same resource.  However, in the case where there are multiple resources added to the knowledge builder that share the same package name then the validateUniqueRuleNames method is not detecting duplicates across the package.
> In cases where rules have the same name and are defined in the same package then I would have expected to get a duplicate rule error but I do not as the rules are physically reside in two separate resources.
> It seems logical that in addition to checking if any rules are duplicated within the resource that it also checks to see that rule was already defined in the package registry as well.  Otherwise the last rule overwrites the first and creates some rather odd behavior.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 10 03:09:23 2011
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Sun, 10 Jul 2011 03:09:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1152) Support Deployment
 introspection using ProtocolMetadata in the Arquillian Containers
In-Reply-To: <2024534842.29230.1309422683684.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <607783596.43425.1310281763863.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

SBS JIRA Integration updated AS7-1152:
--------------------------------------

    Forum Reference: http://community.jboss.org/docs/DOC-17010


> Support Deployment introspection using ProtocolMetadata in the Arquillian Containers
> ------------------------------------------------------------------------------------
>
>                 Key: AS7-1152
>                 URL: https://issues.jboss.org/browse/AS7-1152
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Test Suite
>    Affects Versions: 7.0.0.CR1
>            Reporter: Aslak Knutsen
>
> on deploy, the Arquillian Containers should return a ProtocolMetadata object that describes the content of the Deployment.
> e.g. Which HTTP contexts (ip/port) are there, which Servlets etc. 
> This can be used for injection of URL's to the Deployed context, e.g. @ArquillianResource(MyServlet.class) URL url;
> The same is used by the ServletProtocol to discover the correct web context to call to invoke the test (this does not currently work at all with AS7)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 10 10:28:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sun, 10 Jul 2011 10:28:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1237) File-based
 deployments stop working after either a failed attempt or an undeploy
In-Reply-To: <622871874.43002.1310155643676.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1370373126.43450.1310308103657.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai reassigned AS7-1237:
---------------------------------

    Assignee: jaikiran pai


> File-based deployments stop working after either a failed attempt or an undeploy
> --------------------------------------------------------------------------------
>
>                 Key: AS7-1237
>                 URL: https://issues.jboss.org/browse/AS7-1237
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.CR1
>            Reporter: Jim Crossley
>            Assignee: jaikiran pai
>
> If I create a new, valid war from scratch and copy it to standalone/deployments, AS7 will deploy it fine.  Further, I can touch it or overwrite it and AS7 will redeploy it.  But once I undeploy it, AS7 will never deploy it again, at least not by my touching it.
> Also, if I break it and cause a failed deployment, AS7 will never attempt to redeploy it as a result of my updating it.  Hence, I can't overwrite an invalid war file with a valid one and have it deploy.
> To force a deploy, I must either rename my.war.failed to my.war.dodeploy or use the CLI.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 10 13:15:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sun, 10 Jul 2011 13:15:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-2245) BMT interceptor
 doesn't take into account application exceptions
In-Reply-To: <126239372.22184.1302610713212.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <190100082.43557.1310318124071.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai updated EJBTHREE-2245:
-----------------------------------

    Fix Version/s: depchain-1.0.2
                       (was: depchain-1.0.1)


> BMT interceptor doesn't take into account application exceptions
> ----------------------------------------------------------------
>
>                 Key: EJBTHREE-2245
>                 URL: https://issues.jboss.org/browse/EJBTHREE-2245
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: transactions
>    Affects Versions: depchain-1.0.0-alpha-47
>         Environment: JBoss AS 6.0.0.Final
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: depchain-1.0.2
>
>
> BMT interceptors currently don't check for application exception semantics as mandated by EJB3 spec. See EJB3.1 spec section 14.3.1, Table 16 for details.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 10 13:28:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sun, 10 Jul 2011 13:28:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-9397) Memory leak in
 EJB3.1 no interface view for stateful beans
In-Reply-To: <203354124.33829.1306740120905.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <972723622.43561.1310318903843.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai resolved JBAS-9397.
--------------------------------

    Resolution: Done


Commit r111741 contains a upgrade of EJB3 depchain to 1.0.1 which contains this fix. Marking this as resolved. The fix will be available in the next nightly build http://community.jboss.org/thread/161386

> Memory leak in EJB3.1 no interface view for stateful beans
> ----------------------------------------------------------
>
>                 Key: JBAS-9397
>                 URL: https://issues.jboss.org/browse/JBAS-9397
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 6.0.0.Final
>         Environment: All platforms
>            Reporter: J?rgen Koras
>            Assignee: jaikiran pai
>            Priority: Critical
>             Fix For: 6.1.0
>
>         Attachments: JavassistProxyFactory-patch.txt
>
>
> Using a stateful no-interface bean causes a memory leak in PermGen space. This can easily be reproduced by creating and removing such a bean. On my machine it fails after 22500 instances.
> The problem is that for each instance of a bean a new Proxy-class is generated.
> This is done using javassist framework in the class org.jboss.ejb3.proxy.javassist.JavassistProxyFactory in method createProxy(Class[], InvocationHandler). Here the depreciated javassist method (instance).setHandler(...) is used. Due to documentation (http://www.csg.is.titech.ac.jp/~chiba/javassist/html/javassist/util/proxy/ProxyFactory.html) this call deactivates the cache!
> The solution is simply to remove that call and pass the handler right in the (instance).create(...) method.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Sun Jul 10 13:28:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sun, 10 Jul 2011 13:28:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-2243) Transaction
 problems, possible bug in ApplicationExceptionComponentMetaDataLoaderFactory
In-Reply-To: <241761386.18120.1302522933186.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1333710353.43568.1310318904096.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on EJBTHREE-2243:
----------------------------------------

r111741 commit in AS trunk contains a upgrade of EJB3 depchain to 1.0.1, which contains this fix. This fix will be available in the next nightly build http://community.jboss.org/thread/161386.


> Transaction problems, possible bug in ApplicationExceptionComponentMetaDataLoaderFactory
> ----------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-2243
>                 URL: https://issues.jboss.org/browse/EJBTHREE-2243
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: transactions
>    Affects Versions: depchain-1.0.0-alpha-47
>         Environment: JBoss AS 6.0.0.Final
>            Reporter: Benoit Heinrich
>            Assignee: jaikiran pai
>             Fix For: depchain-1.0.1
>
>
> I think I've found a possible bug with transaction attributes management in jboss 6.0.0 Final.
>  
> The problem appears when using the @TransactionAttribute annotation on an EJB bean with the @Interceptors.
>  
> When using that it seems that the @TransactionAttribute annotation is ignored.
>  
> By removing the @Interceptors annotation it works and the right transaction attribute is used.
>  
> More details available in the jboss forum link.
> Cheers,
> /Benoit

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 10 13:40:23 2011
From: jira-events at lists.jboss.org (=?UTF-8?Q?J=C3=BCrgen_Schiewe_=28JIRA=29?=)
Date: Sun, 10 Jul 2011 13:40:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3036)
 org.antlr.runtime.CommonToken cannot be cast to org.drools.lang.DroolsToken
In-Reply-To: <1054988781.2547.1305565320921.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <164414493.43575.1310319623758.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

J?rgen Schiewe commented on JBRULES-3036:
-----------------------------------------

I was able to reproduce the issue with the Eclipse plugin 5.2.0.v20110116-0638-H14 using a Drools runtime 5.2.0-FINAL.
I will isolate the offending rule and attach the source.

> org.antlr.runtime.CommonToken cannot be cast to org.drools.lang.DroolsToken
> ---------------------------------------------------------------------------
>
>                 Key: JBRULES-3036
>                 URL: https://issues.jboss.org/browse/JBRULES-3036
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.2.0.M2
>            Reporter: Anibal Marques
>            Assignee: Edson Tirelli
>             Fix For: 5.2.0.CR1
>
>
> I Got this Unexpected exception when put rule in a .drl file inside Eclipse (let me know you need something more):
> Unexpected exception raised while parsing. This is a bug. Please contact the Development team :
> java.lang.ClassCastException: org.antlr.runtime.CommonToken cannot be cast to org.drools.lang.DroolsToken
> [org.drools.lang.ParserHelper.emit(ParserHelper.java:89), org.drools.lang.DRLParser.fact(DRLParser.java:9214), org.drools.lang.DRLParser.fact_binding_expression(DRLParser.java:9012), org.drools.lang.DRLParser.fact_binding(DRLParser.java:8890), org.drools.lang.DRLParser.lhs_pattern(DRLParser.java:8713), org.drools.lang.DRLParser.pattern_source(DRLParser.java:7017), org.drools.lang.DRLParser.lhs_unary(DRLParser.java:5846), org.drools.lang.DRLParser.lhs_and(DRLParser.java:5559), org.drools.lang.DRLParser.lhs_or(DRLParser.java:5249), org.drools.lang.DRLParser.lhs(DRLParser.java:5047), org.drools.lang.DRLParser.normal_lhs_block(DRLParser.java:4953), org.drools.lang.DRLParser.when_part(DRLParser.java:3217), org.drools.lang.DRLParser.rule(DRLParser.java:3009), org.drools.lang.DRLParser.statement(DRLParser.java:746), org.drools.lang.DRLParser.compilation_unit(DRLParser.java:340), org.drools.compiler.DrlParser.compile(DrlParser.java:231), org.drools.compiler.DrlParser.parse(DrlParser.java:71), org.drools.eclipse.DroolsEclipsePlugin.generateParsedResource(DroolsEclipsePlugin.java:416), org.drools.eclipse.DroolsEclipsePlugin.generateParsedResource(DroolsEclipsePlugin.java:361), org.drools.eclipse.DroolsEclipsePlugin.parseResource(DroolsEclipsePlugin.java:274), org.drools.eclipse.builder.DroolsBuilder.parseDRLFile(DroolsBuilder.java:279), org.drools.eclipse.builder.DroolsBuilder.parseResource(DroolsBuilder.java:191), org.drools.eclipse.builder.DroolsBuilder$DroolsBuildDeltaVisitor.visit(DroolsBuilder.java:155), org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:68), org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79), org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79), org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79), org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79), org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:48), org.drools.eclipse.builder.DroolsBuilder.incrementalBuild(DroolsBuilder.java:143), org.drools.eclipse.builder.DroolsBuilder.build(DroolsBuilder.java:101), org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:629), org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42), org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:172), org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:203), org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:255), org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42), org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:258), org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:311), org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:343), org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144), org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:242), org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Sun Jul 10 13:51:23 2011
From: jira-events at lists.jboss.org (=?UTF-8?Q?J=C3=BCrgen_Schiewe_=28JIRA=29?=)
Date: Sun, 10 Jul 2011 13:51:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3036)
 org.antlr.runtime.CommonToken cannot be cast to org.drools.lang.DroolsToken
In-Reply-To: <1054988781.2547.1305565320921.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1626582102.43580.1310320283707.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

J?rgen Schiewe commented on JBRULES-3036:
-----------------------------------------

package com.lhsystems.crew.brs.clh

#list any import classes here.
import com.lhsystems.crew.brs.mdl.nlcrewbase.*;
import com.lhsystems.crew.brs.mdl.nlcrewinfo.*;
import com.lhsystems.crew.brs.mdl.nlcrewcheck.*;

rule "checkConnectionTime"
/*
 * Checks the connection time between two duty events.
 * If there is already a message for a time inconsistency between these two
 * duty events, no connection time check is done.
 * In case of two legs on the same aircraft no connection time check is done.
 */
  salience 1
when
    Control(phase == PhaseCheckEvents)
    $dtyEvent: DtyEvent(next != null; $nextDtyEvent: next)
    not NonDtyEvent(! isMarker(),
                    ! isCheckMarker(),
                    beginDt > ?dtyEvent.beginDt,
                    beginDt < ?nextDtyEvent.beginDt)
    not Message(msgNo == 11751,	beginDt == ?dtyEvent.beginDt)
    not Message(msgNo == 11601, beginDt == ?dtyEvent.beginDt)
then
	System.out.println("Hello world");
end


> org.antlr.runtime.CommonToken cannot be cast to org.drools.lang.DroolsToken
> ---------------------------------------------------------------------------
>
>                 Key: JBRULES-3036
>                 URL: https://issues.jboss.org/browse/JBRULES-3036
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.2.0.M2
>            Reporter: Anibal Marques
>            Assignee: Edson Tirelli
>             Fix For: 5.2.0.CR1
>
>
> I Got this Unexpected exception when put rule in a .drl file inside Eclipse (let me know you need something more):
> Unexpected exception raised while parsing. This is a bug. Please contact the Development team :
> java.lang.ClassCastException: org.antlr.runtime.CommonToken cannot be cast to org.drools.lang.DroolsToken
> [org.drools.lang.ParserHelper.emit(ParserHelper.java:89), org.drools.lang.DRLParser.fact(DRLParser.java:9214), org.drools.lang.DRLParser.fact_binding_expression(DRLParser.java:9012), org.drools.lang.DRLParser.fact_binding(DRLParser.java:8890), org.drools.lang.DRLParser.lhs_pattern(DRLParser.java:8713), org.drools.lang.DRLParser.pattern_source(DRLParser.java:7017), org.drools.lang.DRLParser.lhs_unary(DRLParser.java:5846), org.drools.lang.DRLParser.lhs_and(DRLParser.java:5559), org.drools.lang.DRLParser.lhs_or(DRLParser.java:5249), org.drools.lang.DRLParser.lhs(DRLParser.java:5047), org.drools.lang.DRLParser.normal_lhs_block(DRLParser.java:4953), org.drools.lang.DRLParser.when_part(DRLParser.java:3217), org.drools.lang.DRLParser.rule(DRLParser.java:3009), org.drools.lang.DRLParser.statement(DRLParser.java:746), org.drools.lang.DRLParser.compilation_unit(DRLParser.java:340), org.drools.compiler.DrlParser.compile(DrlParser.java:231), org.drools.compiler.DrlParser.parse(DrlParser.java:71), org.drools.eclipse.DroolsEclipsePlugin.generateParsedResource(DroolsEclipsePlugin.java:416), org.drools.eclipse.DroolsEclipsePlugin.generateParsedResource(DroolsEclipsePlugin.java:361), org.drools.eclipse.DroolsEclipsePlugin.parseResource(DroolsEclipsePlugin.java:274), org.drools.eclipse.builder.DroolsBuilder.parseDRLFile(DroolsBuilder.java:279), org.drools.eclipse.builder.DroolsBuilder.parseResource(DroolsBuilder.java:191), org.drools.eclipse.builder.DroolsBuilder$DroolsBuildDeltaVisitor.visit(DroolsBuilder.java:155), org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:68), org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79), org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79), org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79), org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79), org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:48), org.drools.eclipse.builder.DroolsBuilder.incrementalBuild(DroolsBuilder.java:143), org.drools.eclipse.builder.DroolsBuilder.build(DroolsBuilder.java:101), org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:629), org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42), org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:172), org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:203), org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:255), org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42), org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:258), org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:311), org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:343), org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144), org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:242), org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Sun Jul 10 14:00:23 2011
From: jira-events at lists.jboss.org (=?UTF-8?Q?J=C3=BCrgen_Schiewe_=28JIRA=29?=)
Date: Sun, 10 Jul 2011 14:00:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3036)
 org.antlr.runtime.CommonToken cannot be cast to org.drools.lang.DroolsToken
In-Reply-To: <1054988781.2547.1305565320921.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1179887824.43593.1310320823800.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

J?rgen Schiewe commented on JBRULES-3036:
-----------------------------------------

It seems the problem is caused by the ? (question marks) left over from migrating the rule from another vendor's rule language.

> org.antlr.runtime.CommonToken cannot be cast to org.drools.lang.DroolsToken
> ---------------------------------------------------------------------------
>
>                 Key: JBRULES-3036
>                 URL: https://issues.jboss.org/browse/JBRULES-3036
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.2.0.M2
>            Reporter: Anibal Marques
>            Assignee: Edson Tirelli
>             Fix For: 5.2.0.CR1
>
>
> I Got this Unexpected exception when put rule in a .drl file inside Eclipse (let me know you need something more):
> Unexpected exception raised while parsing. This is a bug. Please contact the Development team :
> java.lang.ClassCastException: org.antlr.runtime.CommonToken cannot be cast to org.drools.lang.DroolsToken
> [org.drools.lang.ParserHelper.emit(ParserHelper.java:89), org.drools.lang.DRLParser.fact(DRLParser.java:9214), org.drools.lang.DRLParser.fact_binding_expression(DRLParser.java:9012), org.drools.lang.DRLParser.fact_binding(DRLParser.java:8890), org.drools.lang.DRLParser.lhs_pattern(DRLParser.java:8713), org.drools.lang.DRLParser.pattern_source(DRLParser.java:7017), org.drools.lang.DRLParser.lhs_unary(DRLParser.java:5846), org.drools.lang.DRLParser.lhs_and(DRLParser.java:5559), org.drools.lang.DRLParser.lhs_or(DRLParser.java:5249), org.drools.lang.DRLParser.lhs(DRLParser.java:5047), org.drools.lang.DRLParser.normal_lhs_block(DRLParser.java:4953), org.drools.lang.DRLParser.when_part(DRLParser.java:3217), org.drools.lang.DRLParser.rule(DRLParser.java:3009), org.drools.lang.DRLParser.statement(DRLParser.java:746), org.drools.lang.DRLParser.compilation_unit(DRLParser.java:340), org.drools.compiler.DrlParser.compile(DrlParser.java:231), org.drools.compiler.DrlParser.parse(DrlParser.java:71), org.drools.eclipse.DroolsEclipsePlugin.generateParsedResource(DroolsEclipsePlugin.java:416), org.drools.eclipse.DroolsEclipsePlugin.generateParsedResource(DroolsEclipsePlugin.java:361), org.drools.eclipse.DroolsEclipsePlugin.parseResource(DroolsEclipsePlugin.java:274), org.drools.eclipse.builder.DroolsBuilder.parseDRLFile(DroolsBuilder.java:279), org.drools.eclipse.builder.DroolsBuilder.parseResource(DroolsBuilder.java:191), org.drools.eclipse.builder.DroolsBuilder$DroolsBuildDeltaVisitor.visit(DroolsBuilder.java:155), org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:68), org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79), org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79), org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79), org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:79), org.eclipse.core.internal.events.ResourceDelta.accept(ResourceDelta.java:48), org.drools.eclipse.builder.DroolsBuilder.incrementalBuild(DroolsBuilder.java:143), org.drools.eclipse.builder.DroolsBuilder.build(DroolsBuilder.java:101), org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:629), org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42), org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:172), org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:203), org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:255), org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42), org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:258), org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:311), org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:343), org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144), org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:242), org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Sun Jul 10 15:52:23 2011
From: jira-events at lists.jboss.org (=?UTF-8?Q?Mikael_L=C3=B6nneberg_=28JIRA=29?=)
Date: Sun, 10 Jul 2011 15:52:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3124) Compiler should
 be able to report warnings
Message-ID: <1781362798.43656.1310327543821.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Compiler should be able to report warnings
------------------------------------------

                 Key: JBRULES-3124
                 URL: https://issues.jboss.org/browse/JBRULES-3124
             Project: Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-compiler
    Affects Versions: 5.2.0.Final
            Reporter: Mikael L?nneberg
            Assignee: Mark Proctor
             Fix For: FUTURE


1) add warnings list to packagebuilder
2) add hasWarnings and getWarnings, in mirror of errors.
3) allow hashWarnings and getWarnings to take positive/negative warnings. i.e. ignore duplicate resource (hasWarnings would return false), report duplicate file (is returned in list). This should be some sort of chainable or compositable filter, with sane defaults.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Sun Jul 10 18:36:23 2011
From: jira-events at lists.jboss.org (Dan Allen (JIRA))
Date: Sun, 10 Jul 2011 18:36:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1036) Arquillian Managed
 Container does not honor configured ports
In-Reply-To: <1230876398.1342.1308236243847.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1145168759.43711.1310337383752.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Dan Allen commented on AS7-1036:
--------------------------------

Perhaps the managed configuration can allow for a custom standalone.xml file to be specified, equivalent to the --server-config commandline flag for the startup script.

> Arquillian Managed Container does not honor configured ports
> ------------------------------------------------------------
>
>                 Key: AS7-1036
>                 URL: https://issues.jboss.org/browse/AS7-1036
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Beta3
>            Reporter: Karel Piwko
>
> When starting a managed container, following configuration is not used by Arquillian:
> {code}
> <container qualifier="container" default="true">
>             <configuration>
>                 <property name="jbossHome">target/jbossas-2</property>
>                 <property name="managementPort">19999</property>
>                 <property name="jmxPort">1190</property>
>                 <property name="httpPort">8180</property>
>                 <property name="startupTimeoutInSeconds">180</property>
>             </configuration>
>             <!-- 
>                 [ARQ-425] config parser code not in sync with schema
>                 Make executionType configurable
>              -->
>             <protocol type="jmx-as7">
>                 <configuration>
>                     <property name="executionType">REMOTE</property>
>                 </configuration>
>             </protocol>
>         </container>       
> {code}
> The standalone container is always started on default ports, e.g. 9999, 1099, 8080.
> The ports are defined in standalone.xml and it seems difficult to change them without touching the file. See 
> http://community.jboss.org/thread/168140 for related question.
> This makes customization of the test runs with managed containers difficult and for clusters even more difficult.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 10 18:40:23 2011
From: jira-events at lists.jboss.org (Dan Allen (JIRA))
Date: Sun, 10 Jul 2011 18:40:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1242) arquillian-service is
 only deployed to first container in group
Message-ID: <1378602236.43713.1310337623634.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

arquillian-service is only deployed to first container in group
---------------------------------------------------------------

                 Key: AS7-1242
                 URL: https://issues.jboss.org/browse/AS7-1242
             Project: Application Server 7
          Issue Type: Bug
          Components: Test Suite
    Affects Versions: 7.0.0.CR1
            Reporter: Dan Allen


When using the Arquillian group feature with the JBoss AS 7 remote container adapter, the arquillian-service is only deployed to the first container. For an example of the problem, see the multinode example in the Arquillian showcase [1].

The test only runs if I use servers that already have the arquillian-service deployed.

http://github.com/arquillian/arquillian-showcase

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 10 20:25:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Sun, 10 Jul 2011 20:25:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1226) Doubled word in
	exception message
In-Reply-To: <414964790.40760.1310078363613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <982717160.43751.1310343923655.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved AS7-1226.
---------------------------------

      Assignee: Stuart Douglas
    Resolution: Done


> Doubled word in exception message
> ---------------------------------
>
>                 Key: AS7-1226
>                 URL: https://issues.jboss.org/browse/AS7-1226
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 7.0.0.CR1
>            Reporter: Martin Vecera
>            Assignee: Stuart Douglas
>            Priority: Minor
>
> I had broken EAR deployment and I received the following error which is expected. IMHO there should be only one "class" word in the error message.
> Caused by: java.lang.RuntimeException: Error getting reflective information for class >>class<< org.jboss.test.TaskHelper
> 	at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:70)
> 	at org.jboss.as.ejb3.deployment.processors.dd.EjbConcurrencyProcessor.checkMethodOverrides(EjbConcurrencyProcessor.java:109)
> 	at org.jboss.as.ejb3.deployment.processors.dd.EjbConcurrencyProcessor.deploy(EjbConcurrencyProcessor.java:86)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
> 	... 5 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 10 20:56:24 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Sun, 10 Jul 2011 20:56:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1243) Picketbox is added to
 the deployment with export=true
Message-ID: <1788132178.43817.1310345784244.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Picketbox is added to the deployment with export=true
-----------------------------------------------------

                 Key: AS7-1243
                 URL: https://issues.jboss.org/browse/AS7-1243
             Project: Application Server 7
          Issue Type: Bug
          Components: Security
    Affects Versions: 7.0.0.CR1
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 10 21:09:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Sun, 10 Jul 2011 21:09:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1243) Picketbox is added
 to the deployment with export=true
In-Reply-To: <1788132178.43817.1310345784244.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1652253454.43903.1310346563865.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved AS7-1243.
---------------------------------

    Fix Version/s: 7.0.0.Final
       Resolution: Done


> Picketbox is added to the deployment with export=true
> -----------------------------------------------------
>
>                 Key: AS7-1243
>                 URL: https://issues.jboss.org/browse/AS7-1243
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 7.0.0.CR1
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 7.0.0.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 10 21:11:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Sun, 10 Jul 2011 21:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1228) Resource injection
 does not work for servlets defined in a different module
In-Reply-To: <842608069.40918.1310097503726.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <295779806.43906.1310346683629.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved AS7-1228.
---------------------------------

    Fix Version/s: 7.0.0.Final
       Resolution: Done


> Resource injection does not work for servlets defined in a different module
> ---------------------------------------------------------------------------
>
>                 Key: AS7-1228
>                 URL: https://issues.jboss.org/browse/AS7-1228
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.CR1
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 7.0.0.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 10 21:43:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Sun, 10 Jul 2011 21:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1244) File system
 deployment scanner does not handle sub directories of the deployments
 directory correctly
Message-ID: <1724186210.44011.1310348603616.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

File system deployment scanner does not handle sub directories of the deployments directory correctly
-----------------------------------------------------------------------------------------------------

                 Key: AS7-1244
                 URL: https://issues.jboss.org/browse/AS7-1244
             Project: Application Server 7
          Issue Type: Bug
          Components: Server
    Affects Versions: 7.0.0.CR1
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas
             Fix For: 7.0.0.Final




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 10 21:49:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Sun, 10 Jul 2011 21:49:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1244) File system
 deployment scanner does not handle sub directories of the deployments
 directory correctly
In-Reply-To: <1724186210.44011.1310348603616.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1120928163.44015.1310348963657.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved AS7-1244.
---------------------------------

    Resolution: Done


> File system deployment scanner does not handle sub directories of the deployments directory correctly
> -----------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1244
>                 URL: https://issues.jboss.org/browse/AS7-1244
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 7.0.0.CR1
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 7.0.0.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 10 21:54:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Sun, 10 Jul 2011 21:54:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1234) Hibernate does not
 read/use metadata for orm.xml defined entites
In-Reply-To: <461439061.42234.1310135790589.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <30883525.44020.1310349263991.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas commented on AS7-1234:
-------------------------------------

This did make it into upstream. In addition to creating the jandex index you also need to tell AS7 to import the annotations, using the annotations option for the Dependencies: manifest entry:

Depedencies: com.mycompany.mymodule annotations,com.mycompompany.myothermodule annotations

> Hibernate does not read/use metadata for orm.xml defined entites
> ----------------------------------------------------------------
>
>                 Key: AS7-1234
>                 URL: https://issues.jboss.org/browse/AS7-1234
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta3, 7.0.0.CR1, 7.0.0.Final, 7.0.1.Final, 7.1.0.Alpha1
>         Environment: windows 7, sql server 2008 r2
>            Reporter: Tomaz Cerar
>            Assignee: Scott Marlow
>
> I have setup where we have "common" entities defined in global lib/module that application(war/ear) in then dependent on.
> Then I declare this entities in orm.xml of my application just by class name.
> for instance:
> {code:xml}
> <entity class="com.company.module.Article"/>
> <entity class="com.company.module.Binary"/>
> <entity class="com.company.module.Category"/>
> {code}
> Up until as7/hibernate 4 this worked with no problems, but now it dies with exception "no id defined on entity Article". If I defined id in orm.xml it then finds id field but fails to find anything that is annotated on classes. 
> It looks like metadata is not read for this classes and hibernate sees them as just plain pojo with no annotations.
> I am guessing that problem has to do something with integration with AS7 that now has jandex index for all annotations...

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 10 22:59:23 2011
From: jira-events at lists.jboss.org (Ramesh Reddy (JIRA))
Date: Sun, 10 Jul 2011 22:59:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1245) Allow sub-directories
 under deployment folder
Message-ID: <1179213612.44062.1310353163623.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Allow sub-directories under deployment folder
---------------------------------------------

                 Key: AS7-1245
                 URL: https://issues.jboss.org/browse/AS7-1245
             Project: Application Server 7
          Issue Type: Bug
    Affects Versions: 7.0.0.CR1
            Reporter: Ramesh Reddy


Currently deploying artifacts to sub-folders under "deployments" directory under standalone mode does not seem function correctly.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 10 23:12:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Sun, 10 Jul 2011 23:12:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-1245) Allow sub-directories
 under deployment folder
In-Reply-To: <1179213612.44062.1310353163623.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <912839386.44074.1310353943634.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas closed AS7-1245.
-------------------------------

         Assignee: Stuart Douglas
    Fix Version/s: 7.0.0.Final
       Resolution: Duplicate Issue


> Allow sub-directories under deployment folder
> ---------------------------------------------
>
>                 Key: AS7-1245
>                 URL: https://issues.jboss.org/browse/AS7-1245
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.CR1
>            Reporter: Ramesh Reddy
>            Assignee: Stuart Douglas
>             Fix For: 7.0.0.Final
>
>
> Currently deploying artifacts to sub-folders under "deployments" directory under standalone mode does not seem function correctly.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 10 23:30:28 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Sun, 10 Jul 2011 23:30:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1216)
 NonexistentConversationException when attempting to restore a long-running
 conversation on AS 7 CR1 and not beta3
In-Reply-To: <1250756013.38439.1309992443679.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1513456335.44129.1310355028827.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas commented on AS7-1216:
-------------------------------------

Do you have a test case that you could attach demonstrating this behaviour?

> NonexistentConversationException when attempting to restore a long-running conversation on AS 7 CR1 and not beta3
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1216
>                 URL: https://issues.jboss.org/browse/AS7-1216
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 7.0.0.CR1
>         Environment: Windows XP 32 bit, JBoss AS 7 CR1 and Firefox 5
>            Reporter: Drew Stockdreher
>
> A simple web application which starts a long-running conversation via an 
> <f:event type="preRenderView" listener="#{bean.startConvo}"/> tag. 
>  Selecting from a selectOneMenuList makes an ajax request which was working on the beta3 release of AS 7 is no longer working with the following stacktrace.  This does however still work in IE 7 and Chrome 12 on both beta3 and CR1 releases. 
> 10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1) org.jboss.weld.context.NonexistentConversationException: WELD-000321 No conversation found to restore for id 1
> 10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.jboss.weld.jsf.WeldPhaseListener.activateConversations(WeldPhaseListener.java:108)
> 10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.jboss.weld.jsf.WeldPhaseListener.beforePhase(WeldPhaseListener.java:84)
> 10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1)    at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228)
> 10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1)    at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99)
> 10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1)    at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:111)
> 10:36:11,275 ERROR [stderr] (http--127.0.0.1-8080-1)    at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
> 10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1)    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312)
> 10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> 10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67)
> 10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
> 10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 10:36:11,291 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> 10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> 10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
> 10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49)
> 10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
> 10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 10:36:11,306 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
> 10:36:11,322 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> 10:36:11,322 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667)
> 10:36:11,322 ERROR [stderr] (http--127.0.0.1-8080-1)    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951)
> 10:36:11,322 ERROR [stderr] (http--127.0.0.1-8080-1)    at java.lang.Thread.run(Thread.java:662)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 00:02:24 2011
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Mon, 11 Jul 2011 00:02:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-1146) Source bundle build
	problems
In-Reply-To: <30343530.27926.1309357523789.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1429509398.44172.1310356944211.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jason Greene closed AS7-1146.
-----------------------------

    Resolution: Done


> Source bundle build problems
> ----------------------------
>
>                 Key: AS7-1146
>                 URL: https://issues.jboss.org/browse/AS7-1146
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Build System
>    Affects Versions: 7.0.0.CR1
>         Environment: GitHub, Linux
>            Reporter: Richard Achmatowicz
>            Assignee: Jason Greene
>             Fix For: 7.0.0.Final
>
>
> The source bundle for AS 7.0.0.CR1 tag obtained from GitHub does not build correctly. 
> Jason indicated that "the problem is that build is configured to include the git hash in the binaries so that we can track down where it came from. If you don't have a git repo though it won't work. So we need to add some kind of workaround for this scenario " 
> Steps to reproduce:
> 1. Navigate https://github.com/jbossas/jboss-as/
> 2. Switch tags to 7.0.0.CR1
> 3. Download the zip source bundle for 7.0.0.CR1
> 4. Unzip and build it with maven via .build.sh install -Dmaven.test.skip=true
> The build is unsuccessful and I see the following:
> [INFO] ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] JBoss Application Server: Build Configuration ..... SUCCESS [1.188s]
> [INFO] JBoss Application Server: Parent Aggregator ....... FAILURE [0.323s]
> [INFO] JBoss Application Server: Protocol Utilities ...... SKIPPED
> [snip]
> [INFO] JBoss Application Server Test Suite: Smoke Tests .. SKIPPED
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 4.832s
> [INFO] Finished at: Wed Jun 29 09:57:06 EDT 2011
> [INFO] Final Memory: 59M/434M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal
> org.codehaus.mojo:buildnumber-maven-plugin:1.0:create (default) on project jboss-as-parent: Cannot get the revision information from the
> scm repository :
> [ERROR] Exception while executing SCM command. UnsupportedOperationException
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the command
> [ERROR] mvn <goals> -rf :jboss-as-parent 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 00:04:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 11 Jul 2011 00:04:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1181) CDI interceptors
	enabled randomly
In-Reply-To: <1943372077.33606.1309780223723.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <463398824.44177.1310357063742.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved AS7-1181.
---------------------------------

      Assignee: Stuart Douglas
    Resolution: Done


> CDI interceptors enabled randomly
> ---------------------------------
>
>                 Key: AS7-1181
>                 URL: https://issues.jboss.org/browse/AS7-1181
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 7.0.0.CR1
>            Reporter: Jozef Hartinger
>            Assignee: Stuart Douglas
>            Priority: Blocker
>             Fix For: 7.0.0.Final
>
>
> A CDI interceptor does not seem to be enabled every time a CDI application is deployed.
> To reproduce:
> 1.) Clone https://github.com/seam/compatibility/tree/arquillian-1.0.0.CR1
> 2.) Set JBOSS_HOME to point to JBoss AS 7 CR1 installation
> 3.) run mvn clean test -Darquillian=jbossas-managed-7 -Dtest=EnableInterceptorStressTest
> The EnableInterceptorStressTest executes a simple interceptor testcase (EnableInterceptorTest) 20 times. Out of these 20 deployments, the test fails 6 - 13 times (the number varies randomly).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 00:08:23 2011
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Mon, 11 Jul 2011 00:08:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1208) poor error message
 with type in logging
In-Reply-To: <512096716.37430.1309959143765.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1752906774.44195.1310357303658.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jason Greene reassigned AS7-1208:
---------------------------------

    Assignee: David Lloyd


> poor error message with type in logging
> ---------------------------------------
>
>                 Key: AS7-1208
>                 URL: https://issues.jboss.org/browse/AS7-1208
>             Project: Application Server 7
>          Issue Type: Quality Risk
>            Reporter: Bill Burke
>            Assignee: David Lloyd
>            Priority: Minor
>
> I had a typo in logging config for standalone.xml  "TRACEy" instead of "TRACE"
> I got the obscure message of:
> 09:26:08,720 WARN  [org.jboss.as.controller] Operation ("add") failed - address: ([
>     ("subsystem" => "logging"),
>     ("periodic-rotating-file-handler" => "FILE")
> ])

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 00:24:23 2011
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Mon, 11 Jul 2011 00:24:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1231) Horrible XML parsing
 error reports
In-Reply-To: <51499966.42067.1310132663768.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <587828655.44212.1310358263774.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jason Greene reassigned AS7-1231:
---------------------------------

    Assignee: Jean-Frederic Clere


> Horrible XML parsing error reports
> ----------------------------------
>
>                 Key: AS7-1231
>                 URL: https://issues.jboss.org/browse/AS7-1231
>             Project: Application Server 7
>          Issue Type: Quality Risk
>            Reporter: Bill Burke
>            Assignee: Jean-Frederic Clere
>
> If I make a typo in jboss-web.xml (or any other descriptor for that matter) I get really obscure errors that don't help me debug the problem.  (See below).  Each project really needs to 
> 09:39:14,132 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC00001: Failed to start service jboss.deployment.unit."basic.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."basic.war".PARSE: Failed to process phase PARSE of deployment "basic.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
> 	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_26]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
> 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to parse "/content/basic.war/WEB-INF/jboss-web.xml"
> 	at org.jboss.as.web.deployment.JBossWebParsingDeploymentProcessor.deploy(JBossWebParsingDeploymentProcessor.java:66)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
> 	... 5 more
> Caused by: com.ctc.wstx.exc.WstxParsingException: Received non-all-whitespace CHARACTERS or CDATA event in nextTag().
>  at [row,col {unknown-source}]: [5,4]
> 	at com.ctc.wstx.sr.StreamScanner.constructWfcException(StreamScanner.java:606)
> 	at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:479)
> 	at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:464)
> 	at com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1137)
> 	at org.jboss.metadata.parser.jbossweb.ValveMetaDataParser.parse(ValveMetaDataParser.java:45)
> 	at org.jboss.metadata.parser.jbossweb.JBossWebMetaDataParser.parse(JBossWebMetaDataParser.java:155)
> 	at org.jboss.as.web.deployment.JBossWebParsingDeploymentProcessor.deploy(JBossWebParsingDeploymentProcessor.java:64)
> 	... 6 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 00:26:23 2011
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Mon, 11 Jul 2011 00:26:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1231) Horrible XML
 parsing error reports
In-Reply-To: <51499966.42067.1310132663768.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2044321909.44217.1310358383648.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jason Greene commented on AS7-1231:
-----------------------------------

We do some sanitization in staxmapper for this kind of thing, in case you want to copy that

> Horrible XML parsing error reports
> ----------------------------------
>
>                 Key: AS7-1231
>                 URL: https://issues.jboss.org/browse/AS7-1231
>             Project: Application Server 7
>          Issue Type: Quality Risk
>            Reporter: Bill Burke
>            Assignee: Jean-Frederic Clere
>
> If I make a typo in jboss-web.xml (or any other descriptor for that matter) I get really obscure errors that don't help me debug the problem.  (See below).  Each project really needs to 
> 09:39:14,132 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC00001: Failed to start service jboss.deployment.unit."basic.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."basic.war".PARSE: Failed to process phase PARSE of deployment "basic.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
> 	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_26]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
> 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to parse "/content/basic.war/WEB-INF/jboss-web.xml"
> 	at org.jboss.as.web.deployment.JBossWebParsingDeploymentProcessor.deploy(JBossWebParsingDeploymentProcessor.java:66)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
> 	... 5 more
> Caused by: com.ctc.wstx.exc.WstxParsingException: Received non-all-whitespace CHARACTERS or CDATA event in nextTag().
>  at [row,col {unknown-source}]: [5,4]
> 	at com.ctc.wstx.sr.StreamScanner.constructWfcException(StreamScanner.java:606)
> 	at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:479)
> 	at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:464)
> 	at com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1137)
> 	at org.jboss.metadata.parser.jbossweb.ValveMetaDataParser.parse(ValveMetaDataParser.java:45)
> 	at org.jboss.metadata.parser.jbossweb.JBossWebMetaDataParser.parse(JBossWebMetaDataParser.java:155)
> 	at org.jboss.as.web.deployment.JBossWebParsingDeploymentProcessor.deploy(JBossWebParsingDeploymentProcessor.java:64)
> 	... 6 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 00:34:25 2011
From: jira-events at lists.jboss.org (Marius Bogoevici (JIRA))
Date: Mon, 11 Jul 2011 00:34:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1246) Datasource drivers
 contained in deployments create services identified by deployment's name
Message-ID: <1438216427.44287.1310358865255.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Datasource drivers contained in deployments create services identified by deployment's name
-------------------------------------------------------------------------------------------

                 Key: AS7-1246
                 URL: https://issues.jboss.org/browse/AS7-1246
             Project: Application Server 7
          Issue Type: Bug
          Components: Server
    Affects Versions: 7.0.0.CR1
            Reporter: Marius Bogoevici
            Assignee: Jason Greene


If a deployment packages jars that contain JBDC 4 drivers, the drivers will be deployed automatically as well. However, the name(s) under which they are registered are derived from the name of the parent deployment unit, therefore there will be a clash if there are multiple drivers contained in the deployment.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 01:17:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 11 Jul 2011 01:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1186) EJB interceptor not
	invoked
In-Reply-To: <727231980.34928.1309855103614.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <897477363.44344.1310361443762.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on AS7-1186:
-----------------------------------

Is this still an issue with latest AS7 upstream?


> EJB interceptor not invoked
> ---------------------------
>
>                 Key: AS7-1186
>                 URL: https://issues.jboss.org/browse/AS7-1186
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>         Attachments: testcase-src.zip, testcase.ear
>
>
> I'll provide a testcase showing that an EJB 3 interceptor is not invoked although defined in MEAT-INF/ejb-jar.xml.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 01:19:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 11 Jul 2011 01:19:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1112) EJB annotation
 processing DUP fails to find annotations from classes belonging to jars in
 .ear/lib
In-Reply-To: <156975585.18957.1308907943649.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2094088438.44348.1310361563764.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai updated AS7-1112:
------------------------------

       Fix Version/s: 7.0.0.Final
                          (was: 7.1.0.Alpha1)
    Git Pull Request: https://github.com/jaikiran/jboss-as/tree/AS7-1112  (was: https://github.com/jaikiran/jboss-as/tree/AS7-1112)
     Forum Reference: http://community.jboss.org/message/611776#611776  (was: http://community.jboss.org/message/611776#611776)


> EJB annotation processing DUP fails to find annotations from classes belonging to jars in .ear/lib
> --------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1112
>                 URL: https://issues.jboss.org/browse/AS7-1112
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 7.0.0.CR1
>         Environment: AS7 upstream (June 24 2011)
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 7.0.0.Final
>
>
> Consider the following deployment:
> {code}
> .ear
> |
> |--- lib/lib.jar
> |
> |--- ejb.jar
> {code}
> If ejb.jar contains:
> {code}
> @Stateless
> public class MyBean implements SomeInterface {
> }
> {code}
> and the lib/lib.jar contains the interface:
> {code}
> @Remote
> public interface SomeInterface  {
> ...
> }
> {code}
> then the BusinessViewAnnotationProcessor complains about missing index for the SomeInterface class:
> {code}
> 09:05:28,739 WARN  [org.jboss.as.ejb3.deployment.processors.BusinessViewAnnotationProcessor] (MSC service thread 1-2) Could not read annotations on EJB interface blah.blah.SomeInterface
> {code}
> Please see the referenced forum thread for the details.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 01:41:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 11 Jul 2011 01:41:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1186) EJB interceptor not
	invoked
In-Reply-To: <727231980.34928.1309855103614.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1461553925.44363.1310362883719.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas commented on AS7-1186:
-------------------------------------

The ejb-jar.xml in the app is wrong, it is missing an <interceptors> declaration for the interceptor:

<interceptors>
      <interceptor>
         <interceptor-class>testcase.MyInterceptor</interceptor-class>
      </interceptor>
   </interceptors>

This is required by the spec, but I will change the code to log a warning in this case. 

> EJB interceptor not invoked
> ---------------------------
>
>                 Key: AS7-1186
>                 URL: https://issues.jboss.org/browse/AS7-1186
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>             Fix For: 7.0.0.Final
>
>         Attachments: testcase-src.zip, testcase.ear
>
>
> I'll provide a testcase showing that an EJB 3 interceptor is not invoked although defined in MEAT-INF/ejb-jar.xml.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 01:41:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 11 Jul 2011 01:41:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-1186) EJB interceptor not
	invoked
In-Reply-To: <727231980.34928.1309855103614.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <781884532.44367.1310362883836.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas closed AS7-1186.
-------------------------------

         Assignee: Stuart Douglas
    Fix Version/s: 7.0.0.Final
       Resolution: Cannot Reproduce Bug


> EJB interceptor not invoked
> ---------------------------
>
>                 Key: AS7-1186
>                 URL: https://issues.jboss.org/browse/AS7-1186
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>             Fix For: 7.0.0.Final
>
>         Attachments: testcase-src.zip, testcase.ear
>
>
> I'll provide a testcase showing that an EJB 3 interceptor is not invoked although defined in MEAT-INF/ejb-jar.xml.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 02:27:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 11 Jul 2011 02:27:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-194)
 java.lang.reflect.UndeclaredThrowableException when using
 @ApplicationException in combination with @InterceptorBinding
In-Reply-To: <499367205.11986.1302187413199.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1369001684.44388.1310365643982.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas closed AS7-194.
------------------------------

         Assignee: Stuart Douglas  (was: Marius Bogoevici)
    Fix Version/s: 7.0.0.Final
                       (was: 7.1.0.Alpha1)
       Resolution: Done


> java.lang.reflect.UndeclaredThrowableException when using @ApplicationException in combination with @InterceptorBinding
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-194
>                 URL: https://issues.jboss.org/browse/AS7-194
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CDI / Weld, EJB
>         Environment: AS 7: https://github.com/wolfc/jboss-as/commits/JBAS-9266
>            Reporter: Felix Ullrich
>            Assignee: Stuart Douglas
>             Fix For: 7.0.0.Final
>
>         Attachments: ejbModule.zip
>
>
> If I'm using @InterceptorBinding a thrown Exception out of an EJB marked with @ApplicationException dont reach the client. Instead of the @ApplicationException I get a java.lang.reflect.UndeclaredThrowableException.
> I've attached a minimal example. 
> My client-main-program looks like this:
> {code:title=Bar.java|borderStyle=solid}
> public static void main(final String[] args) throws NamingException {
>                                                                                                                   	                                                                                 
> 	final InitialContext context = new InitialContext();                             
> 	context.lookup("StatefulTestBean/remote");                                       
> 	                                                                                 
> 	try {                                                                            
> 		statefulTest.throwApplicationError();                                        
> 	} catch (final Exception e) {                                                    
> 		System.out.println(e);                                                       
> 	}                                                                                
> }                                                                                    
> {code}
> The excepted output would be: 
> {code}
> error.AppError
> {code}
> but its: 
> {code}
> java.lang.reflect.UndeclaredThrowableException
> {code}
> If you comment out the annotation @InterceptorAnnotation in the StatefulTestBean.java and redeploy the application then everything is fine - you get the expetced AppError-Exception.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 02:29:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 11 Jul 2011 02:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-290) CNFEs for Seam 3
 optional dependencies
In-Reply-To: <1219138147.3885.1301985093084.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1594574640.44409.1310365763812.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved AS7-290.
--------------------------------

    Fix Version/s: 7.0.0.Final
                       (was: 7.1.0.Alpha1)
       Resolution: Done


Should be fixed with the upgrade to weld 1.1.2.AS7

> CNFEs for Seam 3 optional dependencies
> --------------------------------------
>
>                 Key: AS7-290
>                 URL: https://issues.jboss.org/browse/AS7-290
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Modules
>    Affects Versions: 7.0.0.Beta2
>            Reporter: Nicklas Karlsson
>            Assignee: Stuart Douglas
>             Fix For: 7.0.0.Final
>
>
> 7.0.0.Beta3-SNAPSHOT upgraded to Weld 1.1.1.Final
> When deploying a WAR with the seam 3 i18n module I get
> 09:26:34,401 WARN  [org.jboss.modules] (MSC service thread 1-2) Failed to define class org.jboss.seam.international.datetimezone.ForwardingDateTimeZone in Module "deployment.LTK.war:main" from Service Module Loader: java.lang.LinkageError: Failed to link org/jboss/seam/international/datetimezone/ForwardingDateTimeZone (Module "deployment.LTK.war:main" from Service Module Loader)
> 	at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:372) [:1.0.0.Beta17]
> 	at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:248) [:1.0.0.Beta17]
> 	at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:72) [:1.0.0.Beta17]
> 	at org.jboss.modules.Module.loadModuleClass(Module.java:576) [:1.0.0.Beta17]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:176) [:1.0.0.Beta17]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:357) [:1.0.0.Beta17]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:306) [:1.0.0.Beta17]
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:100) [:1.0.0.Beta17]
> 	at org.jboss.as.weld.WeldModuleResourceLoader.classForName(WeldModuleResourceLoader.java:68) [file:C:%5CJava%5CAS%5Cjboss-7.0.0.Beta3-SNAPSHOT%5Cmodules%5Corg%5Cjboss%5Cas%5Cweld%5Cmain%5Cjboss-as-weld-7.0.0.Beta3-SNAPSHOT.jar:7.0.0.Beta3-SNAPSHOT]
> 	at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:83) [file:C:%5CJava%5CAS%5Cjboss-7.0.0.Beta3-SNAPSHOT%5Cmodules%5Corg%5Cjboss%5Cweld%5Ccore%5Cmain%5Cweld-core-1.1.1.Final.jar:2011-04-04 15:54]
> 	at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:133) [file:C:%5CJava%5CAS%5Cjboss-7.0.0.Beta3-SNAPSHOT%5Cmodules%5Corg%5Cjboss%5Cweld%5Ccore%5Cmain%5Cweld-core-1.1.1.Final.jar:2011-04-04 15:54]
> 	at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:192) [file:C:%5CJava%5CAS%5Cjboss-7.0.0.Beta3-SNAPSHOT%5Cmodules%5Corg%5Cjboss%5Cweld%5Ccore%5Cmain%5Cweld-core-1.1.1.Final.jar:2011-04-04 15:54]
> 	at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:370) [file:C:%5CJava%5CAS%5Cjboss-7.0.0.Beta3-SNAPSHOT%5Cmodules%5Corg%5Cjboss%5Cweld%5Ccore%5Cmain%5Cweld-core-1.1.1.Final.jar:2011-04-04 15:54]
> 	at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82) [file:C:%5CJava%5CAS%5Cjboss-7.0.0.Beta3-SNAPSHOT%5Cmodules%5Corg%5Cjboss%5Cas%5Cweld%5Cmain%5Cjboss-as-weld-7.0.0.Beta3-SNAPSHOT.jar:7.0.0.Beta3-SNAPSHOT]
> 	at org.jboss.as.weld.services.WeldService.start(WeldService.java:89) [file:C:%5CJava%5CAS%5Cjboss-7.0.0.Beta3-SNAPSHOT%5Cmodules%5Corg%5Cjboss%5Cas%5Cweld%5Cmain%5Cjboss-as-weld-7.0.0.Beta3-SNAPSHOT.jar:7.0.0.Beta3-SNAPSHOT]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1344)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_23]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_23]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_23]
> Caused by: java.lang.NoClassDefFoundError: org/joda/time/DateTimeZone
> 	at java.lang.ClassLoader.defineClass1(Native Method) [:1.6.0_23]
> 	at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) [:1.6.0_23]
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:616) [:1.6.0_23]
> 	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) [:1.6.0_23]
> 	at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:368) [:1.0.0.Beta17]
> 	... 18 more
> Caused by: java.lang.ClassNotFoundException: org.joda.time.DateTimeZone from [Module "deployment.LTK.war:main" from Service Module Loader]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:184) [:1.0.0.Beta17]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:357) [:1.0.0.Beta17]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:329) [:1.0.0.Beta17]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:329) [:1.0.0.Beta17]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:306) [:1.0.0.Beta17]
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:100) [:1.0.0.Beta17]
> 	... 23 more
> 09:26:34,413 WARN  [org.jboss.modules] (MSC service thread 1-2) Failed to define class org.jboss.seam.international.datetimezone.ForwardingDateTimeZone in Module "deployment.LTK.war:main" from Service Module Loader: java.lang.LinkageError: Failed to link org/jboss/seam/international/datetimezone/ForwardingDateTimeZone (Module "deployment.LTK.war:main" from Service Module Loader)
> 	at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:372) [:1.0.0.Beta17]
> 	at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:248) [:1.0.0.Beta17]
> 	at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:72) [:1.0.0.Beta17]
> 	at org.jboss.modules.Module.loadModuleClass(Module.java:576) [:1.0.0.Beta17]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:176) [:1.0.0.Beta17]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:357) [:1.0.0.Beta17]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:329) [:1.0.0.Beta17]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:306) [:1.0.0.Beta17]
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:100) [:1.0.0.Beta17]
> 	at java.lang.Class.getDeclaredMethods0(Native Method) [:1.6.0_23]
> 	at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) [:1.6.0_23]
> 	at java.lang.Class.getDeclaredMethods(Class.java:1791) [:1.6.0_23]
> 	at org.jboss.weld.util.reflection.SecureReflections$8.work(SecureReflections.java:198) [file:C:%5CJava%5CAS%5Cjboss-7.0.0.Beta3-SNAPSHOT%5Cmodules%5Corg%5Cjboss%5Cweld%5Ccore%5Cmain%5Cweld-core-1.1.1.Final.jar:2011-04-04 15:54]
> 	at org.jboss.weld.util.reflection.SecureReflections$8.work(SecureReflections.java:194) [file:C:%5CJava%5CAS%5Cjboss-7.0.0.Beta3-SNAPSHOT%5Cmodules%5Corg%5Cjboss%5Cweld%5Ccore%5Cmain%5Cweld-core-1.1.1.Final.jar:2011-04-04 15:54]
> 	at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54) [file:C:%5CJava%5CAS%5Cjboss-7.0.0.Beta3-SNAPSHOT%5Cmodules%5Corg%5Cjboss%5Cweld%5Ccore%5Cmain%5Cweld-core-1.1.1.Final.jar:2011-04-04 15:54]
> 	at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:67) [file:C:%5CJava%5CAS%5Cjboss-7.0.0.Beta3-SNAPSHOT%5Cmodules%5Corg%5Cjboss%5Cweld%5Ccore%5Cmain%5Cweld-core-1.1.1.Final.jar:2011-04-04 15:54]
> 	at org.jboss.weld.util.reflection.SecureReflections.getDeclaredMethods(SecureReflections.java:193) [file:C:%5CJava%5CAS%5Cjboss-7.0.0.Beta3-SNAPSHOT%5Cmodules%5Corg%5Cjboss%5Cweld%5Ccore%5Cmain%5Cweld-core-1.1.1.Final.jar:2011-04-04 15:54]
> 	at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:262) [file:C:%5CJava%5CAS%5Cjboss-7.0.0.Beta3-SNAPSHOT%5Cmodules%5Corg%5Cjboss%5Cweld%5Ccore%5Cmain%5Cweld-core-1.1.1.Final.jar:2011-04-04 15:54]
> 	at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:124) [file:C:%5CJava%5CAS%5Cjboss-7.0.0.Beta3-SNAPSHOT%5Cmodules%5Corg%5Cjboss%5Cweld%5Ccore%5Cmain%5Cweld-core-1.1.1.Final.jar:2011-04-04 15:54]
> 	at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:54) [file:C:%5CJava%5CAS%5Cjboss-7.0.0.Beta3-SNAPSHOT%5Cmodules%5Corg%5Cjboss%5Cweld%5Ccore%5Cmain%5Cweld-core-1.1.1.Final.jar:2011-04-04 15:54]
> 	at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:42) [file:C:%5CJava%5CAS%5Cjboss-7.0.0.Beta3-SNAPSHOT%5Cmodules%5Corg%5Cjboss%5Cweld%5Ccore%5Cmain%5Cweld-core-1.1.1.Final.jar:2011-04-04 15:54]
> 	at com.google.common.collect.ComputingConcurrentHashMap.compute(ComputingConcurrentHashMap.java:206)
> 	at com.google.common.collect.ComputingConcurrentHashMap.apply(ComputingConcurrentHashMap.java:100)
> 	at com.google.common.collect.MapMaker$ComputingMapAdapter.get(MapMaker.java:515)
> 	at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:183) [file:C:%5CJava%5CAS%5Cjboss-7.0.0.Beta3-SNAPSHOT%5Cmodules%5Corg%5Cjboss%5Cweld%5Ccore%5Cmain%5Cweld-core-1.1.1.Final.jar:2011-04-04 15:54]
> 	at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:96) [file:C:%5CJava%5CAS%5Cjboss-7.0.0.Beta3-SNAPSHOT%5Cmodules%5Corg%5Cjboss%5Cweld%5Ccore%5Cmain%5Cweld-core-1.1.1.Final.jar:2011-04-04 15:54]
> 	at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:133) [file:C:%5CJava%5CAS%5Cjboss-7.0.0.Beta3-SNAPSHOT%5Cmodules%5Corg%5Cjboss%5Cweld%5Ccore%5Cmain%5Cweld-core-1.1.1.Final.jar:2011-04-04 15:54]
> 	at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:192) [file:C:%5CJava%5CAS%5Cjboss-7.0.0.Beta3-SNAPSHOT%5Cmodules%5Corg%5Cjboss%5Cweld%5Ccore%5Cmain%5Cweld-core-1.1.1.Final.jar:2011-04-04 15:54]
> 	at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:370) [file:C:%5CJava%5CAS%5Cjboss-7.0.0.Beta3-SNAPSHOT%5Cmodules%5Corg%5Cjboss%5Cweld%5Ccore%5Cmain%5Cweld-core-1.1.1.Final.jar:2011-04-04 15:54]
> 	at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82) [file:C:%5CJava%5CAS%5Cjboss-7.0.0.Beta3-SNAPSHOT%5Cmodules%5Corg%5Cjboss%5Cas%5Cweld%5Cmain%5Cjboss-as-weld-7.0.0.Beta3-SNAPSHOT.jar:7.0.0.Beta3-SNAPSHOT]
> 	at org.jboss.as.weld.services.WeldService.start(WeldService.java:89) [file:C:%5CJava%5CAS%5Cjboss-7.0.0.Beta3-SNAPSHOT%5Cmodules%5Corg%5Cjboss%5Cas%5Cweld%5Cmain%5Cjboss-as-weld-7.0.0.Beta3-SNAPSHOT.jar:7.0.0.Beta3-SNAPSHOT]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1344)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_23]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_23]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_23]
> Caused by: java.lang.NoClassDefFoundError: org/joda/time/DateTimeZone
> 	at java.lang.ClassLoader.defineClass1(Native Method) [:1.6.0_23]
> 	at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) [:1.6.0_23]
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:616) [:1.6.0_23]
> 	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) [:1.6.0_23]
> 	at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:368) [:1.0.0.Beta17]
> 	... 34 more
> Caused by: java.lang.ClassNotFoundException: org.joda.time.DateTimeZone from [Module "deployment.LTK.war:main" from Service Module Loader]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:184) [:1.0.0.Beta17]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:357) [:1.0.0.Beta17]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:329) [:1.0.0.Beta17]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:329) [:1.0.0.Beta17]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:306) [:1.0.0.Beta17]
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:100) [:1.0.0.Beta17]
> 	... 39 more
> 09:26:34,440 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.deployment.unit."LTK.war".WeldService: org.jboss.msc.service.StartException in service jboss.deployment.unit."LTK.war".WeldService: com.google.common.collect.ComputationException: java.lang.LinkageError: Failed to link org/jboss/seam/international/datetimezone/ForwardingDateTimeZone (Module "deployment.LTK.war:main" from Service Module Loader)
> 	at org.jboss.as.weld.services.WeldService.start(WeldService.java:96)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1344)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_23]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_23]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_23]
> Caused by: com.google.common.collect.ComputationException: java.lang.LinkageError: Failed to link org/jboss/seam/international/datetimezone/ForwardingDateTimeZone (Module "deployment.LTK.war:main" from Service Module Loader)
> 	at com.google.common.collect.ComputingConcurrentHashMap.compute(ComputingConcurrentHashMap.java:218)
> 	at com.google.common.collect.ComputingConcurrentHashMap.apply(ComputingConcurrentHashMap.java:100)
> 	at com.google.common.collect.MapMaker$ComputingMapAdapter.get(MapMaker.java:515)
> 	at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:183)
> 	at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:96)
> 	at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:133)
> 	at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:192)
> 	at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:370)
> 	at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:82)
> 	at org.jboss.as.weld.services.WeldService.start(WeldService.java:89)
> 	... 4 more
> Caused by: java.lang.LinkageError: Failed to link org/jboss/seam/international/datetimezone/ForwardingDateTimeZone (Module "deployment.LTK.war:main" from Service Module Loader)
> 	at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:372) [jboss-modules.jar:1.0.0.Beta17]
> 	at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:248) [jboss-modules.jar:1.0.0.Beta17]
> 	at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:72) [jboss-modules.jar:1.0.0.Beta17]
> 	at org.jboss.modules.Module.loadModuleClass(Module.java:576) [jboss-modules.jar:1.0.0.Beta17]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:176) [jboss-modules.jar:1.0.0.Beta17]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:357) [jboss-modules.jar:1.0.0.Beta17]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:329) [jboss-modules.jar:1.0.0.Beta17]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:306) [jboss-modules.jar:1.0.0.Beta17]
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:100) [jboss-modules.jar:1.0.0.Beta17]
> 	at java.lang.Class.getDeclaredMethods0(Native Method) [:1.6.0_23]
> 	at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) [:1.6.0_23]
> 	at java.lang.Class.getDeclaredMethods(Class.java:1791) [:1.6.0_23]
> 	at org.jboss.weld.util.reflection.SecureReflections$8.work(SecureReflections.java:198)
> 	at org.jboss.weld.util.reflection.SecureReflections$8.work(SecureReflections.java:194)
> 	at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
> 	at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:67)
> 	at org.jboss.weld.util.reflection.SecureReflections.getDeclaredMethods(SecureReflections.java:193)
> 	at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:262)
> 	at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:124)
> 	at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:54)
> 	at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:42)
> 	at com.google.common.collect.ComputingConcurrentHashMap.compute(ComputingConcurrentHashMap.java:206)
> 	... 13 more
> Caused by: java.lang.NoClassDefFoundError: org/joda/time/DateTimeZone
> 	at java.lang.ClassLoader.defineClass1(Native Method) [:1.6.0_23]
> 	at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) [:1.6.0_23]
> 	at java.lang.ClassLoader.defineClass(ClassLoader.java:616) [:1.6.0_23]
> 	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) [:1.6.0_23]
> 	at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:368) [jboss-modules.jar:1.0.0.Beta17]
> 	... 34 more
> Caused by: java.lang.ClassNotFoundException: org.joda.time.DateTimeZone from [Module "deployment.LTK.war:main" from Service Module Loader]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:184) [jboss-modules.jar:1.0.0.Beta17]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:357) [jboss-modules.jar:1.0.0.Beta17]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:329) [jboss-modules.jar:1.0.0.Beta17]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:329) [jboss-modules.jar:1.0.0.Beta17]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:306) [jboss-modules.jar:1.0.0.Beta17]
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:100) [jboss-modules.jar:1.0.0.Beta17]
> 	... 39 more
> 09:26:34,463 ERROR [org.jboss.as] (MSC service thread 1-1) JBoss AS 7.0.0.Beta3-SNAPSHOT "TBD" started (with errors) in 8363ms - Started 485 of 821 services (17 services failed or missing dependencies, 26 services are passive or on-demand)
>     Services missing dependencies:
>         service jboss.data-source.java:/LTKDatasource
>         service jboss.data-source.reference-factory.java:/LTKDatasource
>         service jboss.deployment.unit."LTK.war".component.Excelmuodostaja.START
>         service jboss.deployment.unit."LTK.war".component.Perustietotoiminnot.START
>         service jboss.deployment.unit."LTK.war".component.Raporttitoiminnot.START
>         service jboss.deployment.unit."LTK.war".component.Siirtokanta.START
>         service jboss.deployment.unit."LTK.war".component.Siirtotoiminnot.START
>         service jboss.jpa.persistenceunit."LTK.war#LTK"
>         service jboss.naming.context.java.comp.LTK.LTK.Excelmuodostaja.env/entityManager
>         service jboss.naming.context.java.comp.LTK.LTK.Perustietotoiminnot.env/kanta
>         service jboss.naming.context.java.comp.LTK.LTK.Raporttitoiminnot.env/entityManager
>         service jboss.naming.context.java.comp.LTK.LTK.Siirtokanta."env/fi.affecto.ltk.siirto.Siirtokanta/datasource"
>         service jboss.naming.context.java.comp.LTK.LTK.Siirtotoiminnot.env/kanta
>         service jboss.naming.context.java.java:/LTKDatasource
>         service jboss.naming.context.java.module.LTK.LTK.env/kanta
>         service jboss.web."LTK.war"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 02:33:39 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 11 Jul 2011 02:33:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-766) EAR and other top level
 deployments should be Atomic
Message-ID: <606822589.44422.1310366019129.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas closed AS7-766.
------------------------------

    Fix Version/s: 7.0.0.Final
       Resolution: Cannot Reproduce Bug


This behaviour is already present

> EAR and other top level deployments should be Atomic
> ----------------------------------------------------
>
>                 Key: AS7-766
>                 URL: https://issues.jboss.org/browse/AS7-766
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Server
>            Reporter: Brad Maxwell
>             Fix For: 7.0.0.Final
>
>
> Issue: If an ear or other deployment that contains sub-deployments is deployed and one of the sub-deployments fails to deploy, the ear should fail and unwind all sub-deployments.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 02:43:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 11 Jul 2011 02:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-944) EJB lifecycle
 interceptors that are not included in the deployment are not applied
In-Reply-To: <1615945077.1997.1307053979335.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <27326569.44472.1310366603931.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved AS7-944.
--------------------------------

    Fix Version/s: 7.0.0.Final
       Resolution: Done


> EJB lifecycle interceptors that are not included in the deployment are not applied
> ----------------------------------------------------------------------------------
>
>                 Key: AS7-944
>                 URL: https://issues.jboss.org/browse/AS7-944
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 7.0.0.Beta3
>            Reporter: Marius Bogoevici
>            Assignee: Stuart Douglas
>             Fix For: 7.0.0.Final
>
>
> Suppose that we have a class
> {code}
> @Startup @Singleton @Interceptors(A.class, B.class)
> public class MyEJB {
> }
> {code}
> Where A.class is included with the deployment and B.class is included in a module that is visible to the deployment.
> B will be identified correctly as an interceptor for MyEJB, but LifecycleAnnotationParsingProcessor will not process it (as it apparently handles only components found within the deployment). Therefore, B will be ignored when creating the interceptor set for MyEJB, since ComponentInstallProcessor will treat it as a class that has no lifecycle methods.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 02:45:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 11 Jul 2011 02:45:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-941) Encountered an
 exception while porting a Seam application from EAP5.x to AS7,
 root cause ZipException
In-Reply-To: <279569647.777.1307025061138.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <776780879.44478.1310366723831.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved AS7-941.
--------------------------------

    Fix Version/s: 7.0.0.Final
       Resolution: Out of Date


This appears to have been fixed already

> Encountered an exception while porting a Seam application from EAP5.x to AS7, root cause ZipException
> -----------------------------------------------------------------------------------------------------
>
>                 Key: AS7-941
>                 URL: https://issues.jboss.org/browse/AS7-941
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: No Release
>         Environment: Fedora 14, porting an EAP5.x application to AS7,
>            Reporter: Sande Gilda
>            Assignee: Ales Justin
>             Fix For: 7.0.0.Final
>
>
> I am porting the TopicIndex application that was built on EAP5.x to AS7. I have worked around a number of ClassNotFound and other issues. My current build is based on git://github.com/jbossejb3/jboss-as.git which as a fix for AS7-910 and I have coded around AS7-896. 
> I am now seeing this exception in the log:
> 09:46:45,570 INFO  [javax.servlet.ServletContextListener] (MSC service thread 1-7) Welcome to Seam null
> 09:46:45,588 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/TopicIndex]] (MSC service thread 1-7) Exception sending context initialized event to listener instance of class org.jboss.seam.servlet.SeamListener: java.lang.RuntimeException: Error handling file /content/TopicIndex.war/WEB-INF/lib/jboss-seam-remoting.jar
> 	at org.jboss.seam.deployment.URLScanner.handleArchiveByFile(URLScanner.java:134) [jboss-seam.jar:]
> 	at org.jboss.seam.deployment.URLScanner.handle(URLScanner.java:107) [jboss-seam.jar:]
> 	at org.jboss.seam.deployment.URLScanner.scanResources(URLScanner.java:90) [jboss-seam.jar:]
> 	at org.jboss.seam.deployment.StandardDeploymentStrategy.scan(StandardDeploymentStrategy.java:119) [jboss-seam.jar:]
> 	at org.jboss.seam.init.Initialization.create(Initialization.java:130) [jboss-seam.jar:]
> 	at org.jboss.seam.servlet.SeamListener.contextInitialized(SeamListener.java:36) [jboss-seam.jar:]
> 	at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3368) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
> 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:3817) [jbossweb-7.0.0.CR1.jar:7.0.0.Beta4-SNAPSHOT]
> 	at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.0.Beta4-SNAPSHOT.jar:7.0.0.Beta4-SNAPSHOT]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_25]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_25]
> Caused by: java.util.zip.ZipException: error in opening zip file
> 	at java.util.zip.ZipFile.open(Native Method) [:1.6.0_25]
> 	at java.util.zip.ZipFile.<init>(ZipFile.java:127) [:1.6.0_25]
> 	at java.util.zip.ZipFile.<init>(ZipFile.java:144) [:1.6.0_25]
> 	at org.jboss.seam.deployment.URLScanner.handleArchiveByFile(URLScanner.java:123) [jboss-seam.jar:]
> 	... 12 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 03:37:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 11 Jul 2011 03:37:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-712) Publish all
 org.jboss.domain.* schemas to http://www.jboss.org/schema/
In-Reply-To: <260965286.28241.1304436318263.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1617938076.44555.1310369843720.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on AS7-712:
----------------------------------

Should we raise a helpdesk ticket for this one, so that Mark Newton and his team and take a look at this?


> Publish all org.jboss.domain.* schemas to http://www.jboss.org/schema/
> ----------------------------------------------------------------------
>
>                 Key: AS7-712
>                 URL: https://issues.jboss.org/browse/AS7-712
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Priority: Blocker
>             Fix For: 7.0.0.Final
>
>
> http://community.jboss.org/wiki/JBossDTDs

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 03:58:23 2011
From: jira-events at lists.jboss.org (Tomaz Zupan (JIRA))
Date: Mon, 11 Jul 2011 03:58:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1247) Messaging
 Configuration not support all setings defined in jboss-messaging.xsd schema
 file.
Message-ID: <38984762.44637.1310371103789.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Messaging Configuration not support all setings defined in jboss-messaging.xsd schema file.
-------------------------------------------------------------------------------------------

                 Key: AS7-1247
                 URL: https://issues.jboss.org/browse/AS7-1247
             Project: Application Server 7
          Issue Type: Bug
          Components: JMS
    Affects Versions: 7.0.0.CR1
         Environment: Windows 7 x64
Java 1.6.25 x64
JBoss 7.0.0 CR1 - standalone-preview
            Reporter: Tomaz Zupan
            Assignee: Clebert Suconic


Only settings included in standalone-preview.xml configuration file are supported. If some other settings from jboss-messaging.xsd schema file are included,  org.jboss.as.controller.persistence.ConfigurationPersistenceException exception is thrown while the JBoss server is starting.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 04:10:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 11 Jul 2011 04:10:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1247) Messaging
 Configuration not support all setings defined in jboss-messaging.xsd schema
 file.
In-Reply-To: <38984762.44637.1310371103789.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1755930661.44650.1310371824026.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on AS7-1247:
-----------------------------------

Can you please attach a standalone xml file which reproduces this issue?


> Messaging Configuration not support all setings defined in jboss-messaging.xsd schema file.
> -------------------------------------------------------------------------------------------
>
>                 Key: AS7-1247
>                 URL: https://issues.jboss.org/browse/AS7-1247
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 7.0.0.CR1
>         Environment: Windows 7 x64
> Java 1.6.25 x64
> JBoss 7.0.0 CR1 - standalone-preview
>            Reporter: Tomaz Zupan
>            Assignee: Clebert Suconic
>              Labels: as7, configuration, jboss, messaging
>
> Only settings included in standalone-preview.xml configuration file are supported. If some other settings from jboss-messaging.xsd schema file are included,  org.jboss.as.controller.persistence.ConfigurationPersistenceException exception is thrown while the JBoss server is starting.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 04:20:31 2011
From: jira-events at lists.jboss.org (Tomaz Zupan (JIRA))
Date: Mon, 11 Jul 2011 04:20:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1247) Messaging
 Configuration not support all setings defined in jboss-messaging.xsd schema
 file.
In-Reply-To: <38984762.44637.1310371103789.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1818466830.44776.1310372431250.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Zupan updated AS7-1247:
-----------------------------

    Attachment: standalone-preview.xml


This is one example, where I include Diverts section. I also tried some other options whith same results.

> Messaging Configuration not support all setings defined in jboss-messaging.xsd schema file.
> -------------------------------------------------------------------------------------------
>
>                 Key: AS7-1247
>                 URL: https://issues.jboss.org/browse/AS7-1247
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 7.0.0.CR1
>         Environment: Windows 7 x64
> Java 1.6.25 x64
> JBoss 7.0.0 CR1 - standalone-preview
>            Reporter: Tomaz Zupan
>            Assignee: Clebert Suconic
>              Labels: as7, configuration, jboss, messaging
>         Attachments: standalone-preview.xml
>
>
> Only settings included in standalone-preview.xml configuration file are supported. If some other settings from jboss-messaging.xsd schema file are included,  org.jboss.as.controller.persistence.ConfigurationPersistenceException exception is thrown while the JBoss server is starting.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 04:44:23 2011
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 11 Jul 2011 04:44:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1234) Hibernate does not
 read/use metadata for orm.xml defined entites
In-Reply-To: <461439061.42234.1310135790589.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1308711259.44859.1310373863713.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar commented on AS7-1234:
----------------------------------

Stuart/Jaikiran tnx for info, I have done all you said it is needed 
-added jandex.idx in META-INF
-in manifest.mf referenced my module with annotations

I can see that app server loads the index (it complains if I rename file) but hibernate still dies with same exception.
I am creating a simple test case that I will attach (sorry I don't know how to register as module via ARQ)

when trace logging is enabled this is what I get just before it dies:

{noformat}
10:42:08,869 DEBUG [org.hibernate.cfg.Configuration] (MSC service thread 1-9) Process annotated classes
10:42:08,873 DEBUG [org.hibernate.cfg.AnnotationBinder] (MSC service thread 1-9) Binding entity from annotated class: com.parsek.cms.Article
10:42:08,892 DEBUG [org.hibernate.cfg.Ejb3Column] (MSC service thread 1-9) Binding column: Ejb3DiscriminatorColumn{logicalColumnName'DTYPE', discriminatorTypeName='string'}
10:42:08,899 DEBUG [org.hibernate.cfg.annotations.EntityBinder] (MSC service thread 1-9) Import with entity name Article
10:42:08,904 DEBUG [org.hibernate.cfg.annotations.EntityBinder] (MSC service thread 1-9) Bind entity com.parsek.cms.Article on table Article
10:42:08,925 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-9) MSC00001: Failed to start service jboss.persistenceunit."ppay-web.war#ppay-web": org.jboss.msc.service.StartException in service jboss.persistenceunit."ppay-web.war#ppay-web": F
ailed to start service
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1786)
        at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
        at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]
Caused by: javax.persistence.PersistenceException: [PersistenceUnit: ppay-web] Unable to build EntityManagerFactory
        at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:903)
        at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:879)
        at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:73)
        at org.jboss.as.jpa.service.PersistenceUnitService.createContainerEntityManagerFactory(PersistenceUnitService.java:170)
        at org.jboss.as.jpa.service.PersistenceUnitService.start(PersistenceUnitService.java:80)
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
        ... 4 more
Caused by: org.hibernate.AnnotationException: No identifier specified for entity: com.parsek.cms.Article
        at org.hibernate.cfg.InheritanceState.determineDefaultAccessType(InheritanceState.java:266)
        at org.hibernate.cfg.InheritanceState.getElementsToProcess(InheritanceState.java:221)
        at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:661)
        at org.hibernate.cfg.Configuration$MetadataSourceQueue.processAnnotatedClassesQueue(Configuration.java:3381)
        at org.hibernate.cfg.Configuration$MetadataSourceQueue.processMetadata(Configuration.java:3335)
        at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1319)
        at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1709)
        at org.hibernate.ejb.EntityManagerFactoryImpl.<init>(EntityManagerFactoryImpl.java:76)
        at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:894)
        ... 9 more
{noformat}

> Hibernate does not read/use metadata for orm.xml defined entites
> ----------------------------------------------------------------
>
>                 Key: AS7-1234
>                 URL: https://issues.jboss.org/browse/AS7-1234
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta3, 7.0.0.CR1, 7.0.0.Final, 7.0.1.Final, 7.1.0.Alpha1
>         Environment: windows 7, sql server 2008 r2
>            Reporter: Tomaz Cerar
>            Assignee: Scott Marlow
>
> I have setup where we have "common" entities defined in global lib/module that application(war/ear) in then dependent on.
> Then I declare this entities in orm.xml of my application just by class name.
> for instance:
> {code:xml}
> <entity class="com.company.module.Article"/>
> <entity class="com.company.module.Binary"/>
> <entity class="com.company.module.Category"/>
> {code}
> Up until as7/hibernate 4 this worked with no problems, but now it dies with exception "no id defined on entity Article". If I defined id in orm.xml it then finds id field but fails to find anything that is annotated on classes. 
> It looks like metadata is not read for this classes and hibernate sees them as just plain pojo with no annotations.
> I am guessing that problem has to do something with integration with AS7 that now has jandex index for all annotations...

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 06:00:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 11 Jul 2011 06:00:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1248) Presence of
 application.xml in .ear causes nested .sar and .war deployments to be
 skipped from deployment
Message-ID: <1875547814.44952.1310378423965.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Presence of application.xml in .ear causes nested .sar and .war deployments to be skipped from deployment
---------------------------------------------------------------------------------------------------------

                 Key: AS7-1248
                 URL: https://issues.jboss.org/browse/AS7-1248
             Project: Application Server 7
          Issue Type: Bug
          Components: EE
    Affects Versions: 7.0.0.CR1
            Reporter: jaikiran pai
            Assignee: jaikiran pai


If a .ear contains a application.xml as follows:

{code:xml}
<application xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
    http://java.sun.com/xml/ns/javaee/application_6.xsd"
    version="6">
</application>
{code}

and also packages nested .sar (and .war) files within the .ear, then those nested deployments are skipped. Removing the application.xml "fixes" the issue. The nested deployment should be picked up even in the presence of the application.xml.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 06:10:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 11 Jul 2011 06:10:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1248) Presence of
 application.xml in .ear causes nested .sar deployment to be skipped from
 deployment
In-Reply-To: <1875547814.44952.1310378423965.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <109935386.44964.1310379023624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai updated AS7-1248:
------------------------------

            Summary: Presence of application.xml in .ear causes nested .sar deployment to be skipped from deployment  (was: Presence of application.xml in .ear causes nested .sar and .war deployments to be skipped from deployment)
         Issue Type: Enhancement  (was: Bug)
        Description: 
If a .ear contains a application.xml as follows:

{code:xml}
<application xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
    http://java.sun.com/xml/ns/javaee/application_6.xsd"
    version="6">
</application>
{code}

and also packages nested .sar files within the .ear, then those nested deployments are skipped. Removing the application.xml "fixes" the issue. 

Since we allow .sar deployments to be picked up even in the absence of application.xml and since (JBoss specific) .sar deployments can't be mapped as a module in application.xml, it would be good to consider these nested .sar deployments, even in the presence of the application.xml.


  was:
If a .ear contains a application.xml as follows:

{code:xml}
<application xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
    http://java.sun.com/xml/ns/javaee/application_6.xsd"
    version="6">
</application>
{code}

and also packages nested .sar (and .war) files within the .ear, then those nested deployments are skipped. Removing the application.xml "fixes" the issue. The nested deployment should be picked up even in the presence of the application.xml.


    Forum Reference: http://community.jboss.org/message/613784#613784  (was: http://community.jboss.org/message/613784#613784)


> Presence of application.xml in .ear causes nested .sar deployment to be skipped from deployment
> -----------------------------------------------------------------------------------------------
>
>                 Key: AS7-1248
>                 URL: https://issues.jboss.org/browse/AS7-1248
>             Project: Application Server 7
>          Issue Type: Enhancement
>          Components: EE
>    Affects Versions: 7.0.0.CR1
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> If a .ear contains a application.xml as follows:
> {code:xml}
> <application xmlns="http://java.sun.com/xml/ns/javaee"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
>     http://java.sun.com/xml/ns/javaee/application_6.xsd"
>     version="6">
> </application>
> {code}
> and also packages nested .sar files within the .ear, then those nested deployments are skipped. Removing the application.xml "fixes" the issue. 
> Since we allow .sar deployments to be picked up even in the absence of application.xml and since (JBoss specific) .sar deployments can't be mapped as a module in application.xml, it would be good to consider these nested .sar deployments, even in the presence of the application.xml.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 06:12:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 11 Jul 2011 06:12:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1248) Presence of
 application.xml in .ear causes nested .sar deployment to be skipped from
 deployment
In-Reply-To: <1875547814.44952.1310378423965.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1647040532.44968.1310379143747.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on AS7-1248:
-----------------------------------

Note that section EE.8.5.2 of Java EE6 spec says:

{quote}
The deployment tool must first read the Java EE application deployment descriptor from the application .ear file (META-INF/application.xml). If the deployment descriptor is present, it fully specifies the modules included in the application. 
{quote}

However, it would be good _not_ to impose this rule for JBoss specific .sar nested deployments because there's no way we can specify a .sar as a module within the application.xml


> Presence of application.xml in .ear causes nested .sar deployment to be skipped from deployment
> -----------------------------------------------------------------------------------------------
>
>                 Key: AS7-1248
>                 URL: https://issues.jboss.org/browse/AS7-1248
>             Project: Application Server 7
>          Issue Type: Enhancement
>          Components: EE
>    Affects Versions: 7.0.0.CR1
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> If a .ear contains a application.xml as follows:
> {code:xml}
> <application xmlns="http://java.sun.com/xml/ns/javaee"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
>     http://java.sun.com/xml/ns/javaee/application_6.xsd"
>     version="6">
> </application>
> {code}
> and also packages nested .sar files within the .ear, then those nested deployments are skipped. Removing the application.xml "fixes" the issue. 
> Since we allow .sar deployments to be picked up even in the absence of application.xml and since (JBoss specific) .sar deployments can't be mapped as a module in application.xml, it would be good to consider these nested .sar deployments, even in the presence of the application.xml.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 06:32:23 2011
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 11 Jul 2011 06:32:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1225) jboss-admin.sh fails
 to exit when run in single command mode
In-Reply-To: <627196052.40655.1310071463653.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1484560681.45001.1310380343711.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Kabir Khan reassigned AS7-1225:
-------------------------------

    Assignee: Kabir Khan  (was: Alexey Loubyansky)


> jboss-admin.sh fails to exit when run in single command mode
> ------------------------------------------------------------
>
>                 Key: AS7-1225
>                 URL: https://issues.jboss.org/browse/AS7-1225
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 7.0.0.Final
>            Reporter: Scott Stark
>            Assignee: Kabir Khan
>         Attachments: CommandLineMain.java.diff
>
>
> This seems to be a new behavior, but regardless it is a problem that breaks other frameworks that call out to the command line shell with a single command and expect it to return. Currently it fails to exit, and callers hang. This is true both in the case of the server running with a management interface, and when one is missing:
> [269](ironmaiden:bin) > ./jboss-admin.sh --connect command=:shutdown
> Connected to standalone controller at localhost:9999
> Communication error: Channel closed
> Closed connection to localhost:9999
> ^C
> [270](ironmaiden:bin) > ./jboss-admin.sh --connect command=:shutdown
> The controller is not available at localhost:9999
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> ^C
> When running a mode where the commands to run are from a file or command line, that is, non-interactive mode, the cli should exit with a status.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 06:47:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 11 Jul 2011 06:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-579) Implement JMS MDB
	integration
In-Reply-To: <373845573.30344.1300298446712.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1181997600.45017.1310381243812.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf commented on AS7-579:
-----------------------------------

{noformat}
java.lang.ClassNotFoundException: org.hornetq.ra.inflow.HornetQActivationSpec from [Module "deployment.ejb3mdb.jar:main" from Service Module Loader]
	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
{noformat}

> Implement JMS MDB integration
> -----------------------------
>
>                 Key: AS7-579
>                 URL: https://issues.jboss.org/browse/AS7-579
>             Project: Application Server 7
>          Issue Type: Sub-task
>            Reporter: David Lloyd
>            Assignee: Carlo de Wolf
>             Fix For: 7.1.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 06:49:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 11 Jul 2011 06:49:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (AS7-493) Integrate
	hornetq-ra.rar into AS 7
In-Reply-To: <1342826652.46712.1300887893374.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1602503488.45022.1310381363797.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf reopened AS7-493:
-------------------------------



The rar classes are not made available to a deployment.

{noformat}
java.lang.ClassNotFoundException: org.hornetq.ra.inflow.HornetQActivationSpec from [Module "deployment.ejb3mdb.jar:main" from Service Module Loader]
	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
{noformat}

> Integrate hornetq-ra.rar into AS 7
> ----------------------------------
>
>                 Key: AS7-493
>                 URL: https://issues.jboss.org/browse/AS7-493
>             Project: Application Server 7
>          Issue Type: Task
>          Components: JMS
>            Reporter: Carlo de Wolf
>            Assignee: Andy Taylor
>             Fix For: 7.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 06:51:24 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 11 Jul 2011 06:51:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1249) Implement
	EndpointDeployer
Message-ID: <1667613146.45046.1310381484258.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Implement EndpointDeployer
--------------------------

                 Key: AS7-1249
                 URL: https://issues.jboss.org/browse/AS7-1249
             Project: Application Server 7
          Issue Type: Sub-task
          Components: JCA
            Reporter: Carlo de Wolf
            Assignee: Jesper Pedersen
            Priority: Critical
             Fix For: 7.1.0.CR1


{noformat}
org.jboss.jca.core.spi.rar.NotFoundException: IJ000855: hornetq-ra isn't registered
	at org.jboss.jca.core.rar.SimpleResourceAdapterRepository.getMessageListeners(SimpleResourceAdapterRepository.java:263)
{noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 06:51:24 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Mon, 11 Jul 2011 06:51:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1182) Incorrect security
 domain selected for web application.
In-Reply-To: <320201656.33784.1309788924180.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <991325048.45050.1310381484380.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Juergen Zimmermann updated AS7-1182:
------------------------------------

    Attachment: test.ear.zip
                testcase-src.zip


Darran, sorry I was out of town last week. I attached a testcase:
* testcase-src.zip contains the sources for an EAR with an EJB module and a web module
* testcase.ear.zip contains the exploded ear.

The security domain is specified in <EAR>/META-INF/jboss-app.xml as it was in JBoss 6. In <web>/WEB-INF/web.xml is a protected URL for a RESTful web service.

You can invoke the web service this way:
http://localhost:8080/testREST/customer/1

The sources of the EAR contain setup.sql: a small script for H2 so that there is a customer with id 1, username 1 and password 1, and having the role 'admin'.

In standalone.xml I add two entries on my Windows box:
* Inside <datasource> for ExampleDS I extended the URL because I placed the script setup.sql in C:\temp:
  ;INIT=RUNSCRIPT FROM 'C:\\temp\\setup.sql'
* Furthermore I added this security domain:
<security-domain name="test" cache-type="default">
<authentication>
<login-module code="Database" flag="required">
<module-option name="dsJndiName" value="java:jboss/datasources/ExampleDS"/>
<module-option name="unauthenticatedIdentity" value="gast"/>
<module-option name="principalsQuery" value="SELECT password FROM user WHERE username=?"/>
<module-option name="rolesQuery" value="SELECT r.role, 'Roles' FROM role r INNER JOIN user u ON r.user_fk = u.id WHERE u.username=?"/>
</login-module>
</authentication>
</security-domain>

> Incorrect security domain selected for web application.
> -------------------------------------------------------
>
>                 Key: AS7-1182
>                 URL: https://issues.jboss.org/browse/AS7-1182
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: Darran Lofthouse
>         Attachments: test.ear.zip, testcase-src.zip
>
>
> I want to migrate from JBossAS 6 to 7.0.0.CR1. In standalone.xml I declare the following security domain, but get the stacktrace (see below) looking for UsersRolesLoginModule instead of DatabaseServerLoginModule.
> Security domain in standalone.xml:
>    <security-domain name="swe2" cache-type="default">
>       <authentication>
>          <login-module code="Database" flag="required">
>             <module-option name="dsJndiName" value="java:/swe2DS"/>
>             <module-option name="unauthenticatedIdentity" value="gast"/>
>             <module-option name="principalsQuery" value="SELECT password FROM kunde WHERE username=?"/>
>             <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM swe2_role r INNER JOIN kunde k ON r.kunde_fk = k.k_id WHERE k.username=?"/>
>             <module-option name="hashAlgorithm" value="SHA-1"/>
>             <module-option name="hashEncoding" value="base64"/>
>          </login-module>
>       </authentication>
>    </security-domain>
> Stacktrace regarding UsersRolesLoginModule (instead of DatabaseServerLoginModule):
> 16:03:58,528 ERROR [org.jboss.security.auth.spi.UsersRolesLoginModule] (http--127.0.0.1-8080-2) Failed to load users/passwords/role files: java.io.IOException: No properties file: users.properties or defaults: defaultUsers.properties found
> 	at org.jboss.security.auth.spi.Util.loadProperties(Util.java:227) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:188) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:202) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:129) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	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 javax.security.auth.login.LoginContext.invoke(LoginContext.java:756) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683) [:1.6.0_26]
> 	at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:579) [:1.6.0_26]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:411) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:154) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:127) [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:180) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:446) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 06:51:24 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 11 Jul 2011 06:51:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-579) Implement JMS MDB
	integration
In-Reply-To: <373845573.30344.1300298446712.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2090838961.45054.1310381484467.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf updated AS7-579:
------------------------------

    Priority: Critical  (was: Major)


> Implement JMS MDB integration
> -----------------------------
>
>                 Key: AS7-579
>                 URL: https://issues.jboss.org/browse/AS7-579
>             Project: Application Server 7
>          Issue Type: Sub-task
>            Reporter: David Lloyd
>            Assignee: Carlo de Wolf
>            Priority: Critical
>             Fix For: 7.1.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 06:56:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 11 Jul 2011 06:56:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1182) Incorrect security
 domain selected for web application.
In-Reply-To: <320201656.33784.1309788924180.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <963675507.45064.1310381783813.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on AS7-1182:
-----------------------------------

I haven't yet looked at the application. But:
{quote}
The security domain is specified in <EAR>/META-INF/jboss-app.xml as it was in JBoss 6
{quote}

Can you try specifying that security domain in the .war/WEB-INF/jboss-web.xml as follows:

{code:xml}
...
<security-domain>test</security-domain>
...
{code}

> Incorrect security domain selected for web application.
> -------------------------------------------------------
>
>                 Key: AS7-1182
>                 URL: https://issues.jboss.org/browse/AS7-1182
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: Darran Lofthouse
>         Attachments: test.ear.zip, testcase-src.zip
>
>
> I want to migrate from JBossAS 6 to 7.0.0.CR1. In standalone.xml I declare the following security domain, but get the stacktrace (see below) looking for UsersRolesLoginModule instead of DatabaseServerLoginModule.
> Security domain in standalone.xml:
>    <security-domain name="swe2" cache-type="default">
>       <authentication>
>          <login-module code="Database" flag="required">
>             <module-option name="dsJndiName" value="java:/swe2DS"/>
>             <module-option name="unauthenticatedIdentity" value="gast"/>
>             <module-option name="principalsQuery" value="SELECT password FROM kunde WHERE username=?"/>
>             <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM swe2_role r INNER JOIN kunde k ON r.kunde_fk = k.k_id WHERE k.username=?"/>
>             <module-option name="hashAlgorithm" value="SHA-1"/>
>             <module-option name="hashEncoding" value="base64"/>
>          </login-module>
>       </authentication>
>    </security-domain>
> Stacktrace regarding UsersRolesLoginModule (instead of DatabaseServerLoginModule):
> 16:03:58,528 ERROR [org.jboss.security.auth.spi.UsersRolesLoginModule] (http--127.0.0.1-8080-2) Failed to load users/passwords/role files: java.io.IOException: No properties file: users.properties or defaults: defaultUsers.properties found
> 	at org.jboss.security.auth.spi.Util.loadProperties(Util.java:227) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:188) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:202) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:129) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	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 javax.security.auth.login.LoginContext.invoke(LoginContext.java:756) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683) [:1.6.0_26]
> 	at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:579) [:1.6.0_26]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:411) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:154) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:127) [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:180) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:446) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 06:58:26 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 11 Jul 2011 06:58:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1182) Incorrect security
 domain selected for web application.
In-Reply-To: <320201656.33784.1309788924180.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <277912387.45069.1310381906182.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse commented on AS7-1182:
---------------------------------------

Thanks for the attachment, I will have a look - it sounds like the security domain in the jboss-app.xml is not getting picked up.

> Incorrect security domain selected for web application.
> -------------------------------------------------------
>
>                 Key: AS7-1182
>                 URL: https://issues.jboss.org/browse/AS7-1182
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: Darran Lofthouse
>         Attachments: test.ear.zip, testcase-src.zip
>
>
> I want to migrate from JBossAS 6 to 7.0.0.CR1. In standalone.xml I declare the following security domain, but get the stacktrace (see below) looking for UsersRolesLoginModule instead of DatabaseServerLoginModule.
> Security domain in standalone.xml:
>    <security-domain name="swe2" cache-type="default">
>       <authentication>
>          <login-module code="Database" flag="required">
>             <module-option name="dsJndiName" value="java:/swe2DS"/>
>             <module-option name="unauthenticatedIdentity" value="gast"/>
>             <module-option name="principalsQuery" value="SELECT password FROM kunde WHERE username=?"/>
>             <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM swe2_role r INNER JOIN kunde k ON r.kunde_fk = k.k_id WHERE k.username=?"/>
>             <module-option name="hashAlgorithm" value="SHA-1"/>
>             <module-option name="hashEncoding" value="base64"/>
>          </login-module>
>       </authentication>
>    </security-domain>
> Stacktrace regarding UsersRolesLoginModule (instead of DatabaseServerLoginModule):
> 16:03:58,528 ERROR [org.jboss.security.auth.spi.UsersRolesLoginModule] (http--127.0.0.1-8080-2) Failed to load users/passwords/role files: java.io.IOException: No properties file: users.properties or defaults: defaultUsers.properties found
> 	at org.jboss.security.auth.spi.Util.loadProperties(Util.java:227) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:188) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:202) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:129) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	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 javax.security.auth.login.LoginContext.invoke(LoginContext.java:756) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683) [:1.6.0_26]
> 	at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:579) [:1.6.0_26]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:411) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:154) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:127) [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:180) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:446) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 07:36:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 11 Jul 2011 07:36:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1234) Hibernate does not
 read/use metadata for orm.xml defined entites
In-Reply-To: <461439061.42234.1310135790589.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1474452983.45093.1310384183690.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on AS7-1234:
-----------------------------------

Have you tried using the latest AS7 nightly build?  Stuart mentioned above that his change is in "upstream", which means he committed the fix but it may not be in an official build yet.

http://community.jboss.org/thread/167590 will give you the link to get the nightly build.

> Hibernate does not read/use metadata for orm.xml defined entites
> ----------------------------------------------------------------
>
>                 Key: AS7-1234
>                 URL: https://issues.jboss.org/browse/AS7-1234
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta3, 7.0.0.CR1, 7.0.0.Final, 7.0.1.Final, 7.1.0.Alpha1
>         Environment: windows 7, sql server 2008 r2
>            Reporter: Tomaz Cerar
>            Assignee: Scott Marlow
>
> I have setup where we have "common" entities defined in global lib/module that application(war/ear) in then dependent on.
> Then I declare this entities in orm.xml of my application just by class name.
> for instance:
> {code:xml}
> <entity class="com.company.module.Article"/>
> <entity class="com.company.module.Binary"/>
> <entity class="com.company.module.Category"/>
> {code}
> Up until as7/hibernate 4 this worked with no problems, but now it dies with exception "no id defined on entity Article". If I defined id in orm.xml it then finds id field but fails to find anything that is annotated on classes. 
> It looks like metadata is not read for this classes and hibernate sees them as just plain pojo with no annotations.
> I am guessing that problem has to do something with integration with AS7 that now has jandex index for all annotations...

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 07:48:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 11 Jul 2011 07:48:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1233) HornetQ RA gives
 NPE when no activationSpecs are supplied
In-Reply-To: <1852884591.42102.1310134463614.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1386995480.45112.1310384903928.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf commented on AS7-1233:
------------------------------------

If I have no resource adapter association, endpoint activation should also fail with some {{ResourceException}}.
{noformat}
13:40:32,879 WARN  [org.hornetq.ra.inflow.HornetQActivation] (jca-short-running-threads-threads - 3) Failure in HornetQ activation org.hornetq.ra.inflow.HornetQActivationSpec(ra=null destination=null destinationType=null ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15): java.lang.NullPointerException
	at org.hornetq.ra.inflow.HornetQActivationSpec.getParsedJndiParams(HornetQActivationSpec.java:183) [hornetq-ra-2.2.6.Final.jar:]
	at org.hornetq.ra.inflow.HornetQActivation.setupDestination(HornetQActivation.java:401) [hornetq-ra-2.2.6.Final.jar:]
	at org.hornetq.ra.inflow.HornetQActivation.setup(HornetQActivation.java:283) [hornetq-ra-2.2.6.Final.jar:]
	at org.hornetq.ra.inflow.HornetQActivation$SetupActivation.run(HornetQActivation.java:587) [hornetq-ra-2.2.6.Final.jar:]
	at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:211)
	at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)
	at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:801)
	at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)
	at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:821)
	at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122)
{noformat}

> HornetQ RA gives NPE when no activationSpecs are supplied
> ---------------------------------------------------------
>
>                 Key: AS7-1233
>                 URL: https://issues.jboss.org/browse/AS7-1233
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: Carlo de Wolf
>            Priority: Minor
>
> {noformat}
> java.lang.NullPointerException
> 	at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:882) [:1.6.0_24]
> 	at org.hornetq.ra.HornetQResourceAdapter.endpointActivation(HornetQResourceAdapter.java:155)
> 	at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:163)
> 	at org.jboss.as.ee.component.ComponentStartService.start(ComponentStartService.java:44)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> 	... 4 more
> {noformat}
> It should throw a {{NotSupportedException}}.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 07:50:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 11 Jul 2011 07:50:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1233) HornetQ RA gives
 NPE when no activationSpecs are supplied
In-Reply-To: <1852884591.42102.1310134463614.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1308951728.45117.1310385023679.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf commented on AS7-1233:
------------------------------------

Another NPE.
{noformat}
13:45:15,114 WARN  [org.hornetq.ra.inflow.HornetQActivation] (jca-short-running-threads-threads - 1) Failure in HornetQ activation org.hornetq.ra.inflow.HornetQActivationSpec(ra=org.hornetq.ra.HornetQResourceAdapter at 6a9c98e8 destination=null destinationType=null ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15): java.lang.NullPointerException
	at javax.naming.NameImpl.<init>(NameImpl.java:264) [:1.6.0_24]
	at javax.naming.CompositeName.<init>(CompositeName.java:214) [:1.6.0_24]
	at org.jboss.as.naming.util.NameParser.parse(NameParser.java:49)
	at org.jboss.as.naming.NamingContext.parseName(NamingContext.java:393)
	at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
	at javax.naming.InitialContext.lookup(InitialContext.java:392) [:1.6.0_24]
	at org.hornetq.ra.Util.lookup(Util.java:174) [hornetq-ra-2.2.6.Final.jar:]
	at org.hornetq.ra.inflow.HornetQActivation.setupDestination(HornetQActivation.java:462) [hornetq-ra-2.2.6.Final.jar:]
	at org.hornetq.ra.inflow.HornetQActivation.setup(HornetQActivation.java:283) [hornetq-ra-2.2.6.Final.jar:]
	at org.hornetq.ra.inflow.HornetQActivation$SetupActivation.run(HornetQActivation.java:587) [hornetq-ra-2.2.6.Final.jar:]
	at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:211)
	at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)
	at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:801)
	at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)
	at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:821)
	at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122)
{noformat}

> HornetQ RA gives NPE when no activationSpecs are supplied
> ---------------------------------------------------------
>
>                 Key: AS7-1233
>                 URL: https://issues.jboss.org/browse/AS7-1233
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: Carlo de Wolf
>            Priority: Minor
>
> {noformat}
> java.lang.NullPointerException
> 	at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:882) [:1.6.0_24]
> 	at org.hornetq.ra.HornetQResourceAdapter.endpointActivation(HornetQResourceAdapter.java:155)
> 	at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:163)
> 	at org.jboss.as.ee.component.ComponentStartService.start(ComponentStartService.java:44)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> 	... 4 more
> {noformat}
> It should throw a {{NotSupportedException}}.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 07:50:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 11 Jul 2011 07:50:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1233) HornetQ RA gives NPE
 when no activationSpecs are supplied
In-Reply-To: <1852884591.42102.1310134463614.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1480160341.45120.1310385023763.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf updated AS7-1233:
-------------------------------

    Priority: Major  (was: Minor)


> HornetQ RA gives NPE when no activationSpecs are supplied
> ---------------------------------------------------------
>
>                 Key: AS7-1233
>                 URL: https://issues.jboss.org/browse/AS7-1233
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: Carlo de Wolf
>
> {noformat}
> java.lang.NullPointerException
> 	at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:882) [:1.6.0_24]
> 	at org.hornetq.ra.HornetQResourceAdapter.endpointActivation(HornetQResourceAdapter.java:155)
> 	at org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent.start(MessageDrivenComponent.java:163)
> 	at org.jboss.as.ee.component.ComponentStartService.start(ComponentStartService.java:44)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> 	... 4 more
> {noformat}
> It should throw a {{NotSupportedException}}.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 08:21:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 11 Jul 2011 08:21:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1249) Implement
	EndpointDeployer
In-Reply-To: <1667613146.45046.1310381484258.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1089698160.45160.1310386883666.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen commented on AS7-1249:
--------------------------------------

Test case in IronJacamar: http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/jboss-jca/trunk/core/src/test/java/org/jboss/jca/core/inflow/HornetQTestCase.java?revision=110802&view=markup

> Implement EndpointDeployer
> --------------------------
>
>                 Key: AS7-1249
>                 URL: https://issues.jboss.org/browse/AS7-1249
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: JCA
>            Reporter: Carlo de Wolf
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 7.1.0.CR1
>
>
> {noformat}
> org.jboss.jca.core.spi.rar.NotFoundException: IJ000855: hornetq-ra isn't registered
> 	at org.jboss.jca.core.rar.SimpleResourceAdapterRepository.getMessageListeners(SimpleResourceAdapterRepository.java:263)
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 08:25:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 11 Jul 2011 08:25:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1249) Implement
	EndpointDeployer
In-Reply-To: <1667613146.45046.1310381484258.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <34563266.45164.1310387123656.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf commented on AS7-1249:
------------------------------------

{code:java}
/**
 * Connector 1.6 13.4.3 Endpoint Deployer
 * The endpoint deployer is a human who has the responsibility to deploy the message
 * endpoint, or application, on an application server. The deployer is expected to know
 * the requirements of the application and be aware of the details of the runtime
 * environment in which the application will be deployed.
 *
 * In JBoss we have automated the endpoint deployer. :-)
 *
 * @author <a href="mailto:cdewolf at redhat.com">Carlo de Wolf</a>
 */
public interface EndpointDeployer {
    /**
     * The deployer configures an ActivationSpec JavaBean instance based on the
     * information provided by the application developer or assembler, which is contained
     * in the endpoint deployment descriptor or by way of metadata annotations described
     * in Section 18.7, ?@Activation? on page 18-14. The deployer may also use additional
     * message provider-specific information to configure the ActivationSpec JavaBean
     * instance.
     *
     * @param resourceAdapterName       the name of the resource adapter to use
     * @param messageListenerInterface  the listener interface of the endpoint
     * @param beanProps                 the standard and provider-specific information for configuring the activation spec
     * @param classLoader               the class loader which holds the activation spec class
     * @return
     */
    ActivationSpec createActivationSpecs(String resourceAdapterName, Class<?> messageListenerInterface, Properties beanProps, ClassLoader classLoader);
}
{code}

> Implement EndpointDeployer
> --------------------------
>
>                 Key: AS7-1249
>                 URL: https://issues.jboss.org/browse/AS7-1249
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: JCA
>            Reporter: Carlo de Wolf
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 7.1.0.CR1
>
>
> {noformat}
> org.jboss.jca.core.spi.rar.NotFoundException: IJ000855: hornetq-ra isn't registered
> 	at org.jboss.jca.core.rar.SimpleResourceAdapterRepository.getMessageListeners(SimpleResourceAdapterRepository.java:263)
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul 11 08:27:23 2011
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 11 Jul 2011 08:27:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1234) Hibernate does not
 read/use metadata for orm.xml defined entites
In-Reply-To: <461439061.42234.1310135790589.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2080601840.45169.1310387243743.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar commented on AS7-1234:
----------------------------------

Scott, I am using git master and build it myself, only difference from master is that i have included build it with Hiberate4-beta3 instead of beta1...

fixes from Stuart are in place, I have double checked it.

> Hibernate does not read/use metadata for orm.xml defined entites
> ----------------------------------------------------------------
>
>                 Key: AS7-1234
>                 URL: https://issues.jboss.org/browse/AS7-1234
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta3, 7.0.0.CR1, 7.0.0.Final, 7.0.1.Final, 7.1.0.Alpha1
>         Environment: windows 7, sql server 2008 r2
>            Reporter: Tomaz Cerar
>            Assignee: Scott Marlow
>
> I have setup where we have "common" entities defined in global lib/module that application(war/ear) in then dependent on.
> Then I declare this entities in orm.xml of my application just by class name.
> for instance:
> {code:xml}
> <entity class="com.company.module.Article"/>
> <entity class="com.company.module.Binary"/>
> <entity class="com.company.module.Category"/>
> {code}
> Up until as7/hibernate 4 this worked with no problems, but now it dies with exception "no id defined on entity Article". If I defined id in orm.xml it then finds id field but fails to find anything that is annotated on classes. 
> It looks like metadata is not read for this classes and hibernate sees them as just plain pojo with no annotations.
> I am guessing that problem has to do something with integration with AS7 that now has jandex index for all annotations...

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 08:35:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 11 Jul 2011 08:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1249) Implement
	EndpointDeployer
In-Reply-To: <1667613146.45046.1310381484258.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <718742174.45200.1310387723683.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen commented on AS7-1249:
--------------------------------------

The key in ResourceAdapterRegistry isn't a resource adapter name - as there can be multiple deployments of the same resource adapter - hence it is an unique identifier.

The EndpointDeployer interface will assume there is only one deployment of a resource adapter instance.

> Implement EndpointDeployer
> --------------------------
>
>                 Key: AS7-1249
>                 URL: https://issues.jboss.org/browse/AS7-1249
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: JCA
>            Reporter: Carlo de Wolf
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 7.1.0.CR1
>
>
> {noformat}
> org.jboss.jca.core.spi.rar.NotFoundException: IJ000855: hornetq-ra isn't registered
> 	at org.jboss.jca.core.rar.SimpleResourceAdapterRepository.getMessageListeners(SimpleResourceAdapterRepository.java:263)
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 08:43:23 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Mon, 11 Jul 2011 08:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1249) Implement
	EndpointDeployer
In-Reply-To: <1667613146.45046.1310381484258.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1929289984.45206.1310388203704.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefano Maestri reassigned AS7-1249:
------------------------------------

    Assignee: Stefano Maestri  (was: Jesper Pedersen)


> Implement EndpointDeployer
> --------------------------
>
>                 Key: AS7-1249
>                 URL: https://issues.jboss.org/browse/AS7-1249
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: JCA
>            Reporter: Carlo de Wolf
>            Assignee: Stefano Maestri
>            Priority: Critical
>             Fix For: 7.1.0.CR1
>
>
> {noformat}
> org.jboss.jca.core.spi.rar.NotFoundException: IJ000855: hornetq-ra isn't registered
> 	at org.jboss.jca.core.rar.SimpleResourceAdapterRepository.getMessageListeners(SimpleResourceAdapterRepository.java:263)
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 08:51:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Mon, 11 Jul 2011 08:51:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (AS7-1186) EJB interceptor not
	invoked
In-Reply-To: <727231980.34928.1309855103614.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1139003540.45218.1310388683654.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Juergen Zimmermann reopened AS7-1186:
-------------------------------------



Please see the lines starting at line no. 1770 at http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd. There is no encapsulating <interceptors> :
        <interceptor-binding>
        <ejb-name>*</ejb-name>
        <interceptor-class>INTERCEPTOR</interceptor-class>
        </interceptor-binding>

> EJB interceptor not invoked
> ---------------------------
>
>                 Key: AS7-1186
>                 URL: https://issues.jboss.org/browse/AS7-1186
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>             Fix For: 7.0.0.Final
>
>         Attachments: testcase-src.zip, testcase.ear
>
>
> I'll provide a testcase showing that an EJB 3 interceptor is not invoked although defined in MEAT-INF/ejb-jar.xml.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 08:56:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Mon, 11 Jul 2011 08:56:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-1186) EJB interceptor not
	invoked
In-Reply-To: <727231980.34928.1309855103614.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1008886572.45226.1310388983653.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Juergen Zimmermann closed AS7-1186.
-----------------------------------

    Resolution: Rejected


OK, I see that <interceptors> must be an tag in addition to <assembly-descriptor>. This wasn't the case with JBoss 6.

> EJB interceptor not invoked
> ---------------------------
>
>                 Key: AS7-1186
>                 URL: https://issues.jboss.org/browse/AS7-1186
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>             Fix For: 7.0.0.Final
>
>         Attachments: testcase-src.zip, testcase.ear
>
>
> I'll provide a testcase showing that an EJB 3 interceptor is not invoked although defined in MEAT-INF/ejb-jar.xml.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 09:11:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 11 Jul 2011 09:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1250) Wrap XAResource by
 default for datasources
Message-ID: <1087050933.45258.1310389883723.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Wrap XAResource by default for datasources
------------------------------------------

                 Key: AS7-1250
                 URL: https://issues.jboss.org/browse/AS7-1250
             Project: Application Server 7
          Issue Type: Task
          Components: JCA
    Affects Versions: 7.0.0.CR1
            Reporter: Jesper Pedersen
            Assignee: Stefano Maestri
             Fix For: 7.1.0.Alpha1


For XA datasources if nothing is specified for in regards to wrapping of XAResource the default should be true.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 09:16:24 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Mon, 11 Jul 2011 09:16:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1182) Incorrect security
 domain selected for web application.
In-Reply-To: <320201656.33784.1309788924180.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1776352736.45290.1310390184201.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Juergen Zimmermann commented on AS7-1182:
-----------------------------------------

I added <security-domain>test</security-domain> to both jboss.xml in the EJB module, and to jboss-web.xml in the web module: The issue is gone. It sounds like <security-domain> in jboss-app.xml is ignored.

> Incorrect security domain selected for web application.
> -------------------------------------------------------
>
>                 Key: AS7-1182
>                 URL: https://issues.jboss.org/browse/AS7-1182
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: Darran Lofthouse
>         Attachments: test.ear.zip, testcase-src.zip
>
>
> I want to migrate from JBossAS 6 to 7.0.0.CR1. In standalone.xml I declare the following security domain, but get the stacktrace (see below) looking for UsersRolesLoginModule instead of DatabaseServerLoginModule.
> Security domain in standalone.xml:
>    <security-domain name="swe2" cache-type="default">
>       <authentication>
>          <login-module code="Database" flag="required">
>             <module-option name="dsJndiName" value="java:/swe2DS"/>
>             <module-option name="unauthenticatedIdentity" value="gast"/>
>             <module-option name="principalsQuery" value="SELECT password FROM kunde WHERE username=?"/>
>             <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM swe2_role r INNER JOIN kunde k ON r.kunde_fk = k.k_id WHERE k.username=?"/>
>             <module-option name="hashAlgorithm" value="SHA-1"/>
>             <module-option name="hashEncoding" value="base64"/>
>          </login-module>
>       </authentication>
>    </security-domain>
> Stacktrace regarding UsersRolesLoginModule (instead of DatabaseServerLoginModule):
> 16:03:58,528 ERROR [org.jboss.security.auth.spi.UsersRolesLoginModule] (http--127.0.0.1-8080-2) Failed to load users/passwords/role files: java.io.IOException: No properties file: users.properties or defaults: defaultUsers.properties found
> 	at org.jboss.security.auth.spi.Util.loadProperties(Util.java:227) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:188) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:202) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:129) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	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 javax.security.auth.login.LoginContext.invoke(LoginContext.java:756) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683) [:1.6.0_26]
> 	at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:579) [:1.6.0_26]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:411) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:154) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:127) [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:180) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:446) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 09:29:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 11 Jul 2011 09:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1249) Implement
	EndpointDeployer
In-Reply-To: <1667613146.45046.1310381484258.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1021709450.45302.1310390963771.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf commented on AS7-1249:
------------------------------------

https://github.com/wolfc/jboss-as/tree/AS7-579

> Implement EndpointDeployer
> --------------------------
>
>                 Key: AS7-1249
>                 URL: https://issues.jboss.org/browse/AS7-1249
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: JCA
>            Reporter: Carlo de Wolf
>            Assignee: Stefano Maestri
>            Priority: Critical
>             Fix For: 7.1.0.CR1
>
>
> {noformat}
> org.jboss.jca.core.spi.rar.NotFoundException: IJ000855: hornetq-ra isn't registered
> 	at org.jboss.jca.core.rar.SimpleResourceAdapterRepository.getMessageListeners(SimpleResourceAdapterRepository.java:263)
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 09:31:23 2011
From: jira-events at lists.jboss.org (Quentin Caillard (JIRA))
Date: Mon, 11 Jul 2011 09:31:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-3123) [Regression] .rf
 file raises a null pointer exception when it is loaded
In-Reply-To: <1509811794.41878.1310129063858.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <695755882.45307.1310391083892.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Quentin Caillard updated JBRULES-3123:
--------------------------------------

    Summary: [Regression] .rf file raises a null pointer exception when it is loaded  (was: .rf file raises a null pointer exception when it is loaded)


> [Regression] .rf file raises a null pointer exception when it is loaded
> -----------------------------------------------------------------------
>
>                 Key: JBRULES-3123
>                 URL: https://issues.jboss.org/browse/JBRULES-3123
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.2.0.Final
>            Reporter: Quentin Caillard
>            Assignee: Mark Proctor
>         Attachments: jUnitTest.tar.gz, jUnitTest.tar.gz
>
>
> I have just switched from version 5.1.1 to 5.2.0.Final
> I have a ruleflow (.rf) file which can be loaded. I have the following stack trace :
> java.lang.NullPointerException
> 	at org.drools.compiler.PackageBuilder.addProcessFromXml(PackageBuilder.java:516)
> 	at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:556)
> 	at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:28)
> 	at com.ariadnext.NewDroolsTest$RulesUtils.loadRules(NewDroolsTest.java:107)
> I made a simple junit test which reproduces the bug.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 09:47:23 2011
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 11 Jul 2011 09:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1159) Running commands
 from file in CLI without a connection fails with a hidden
 NullPointerException - Failed to execute batch: null
In-Reply-To: <663893685.29701.1309430723779.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1842335372.45331.1310392043894.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Alexey Loubyansky resolved AS7-1159.
------------------------------------

    Resolution: Done


This has been fixed.

> Running commands from file in CLI without a connection fails with a hidden NullPointerException - Failed to execute batch: null
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1159
>                 URL: https://issues.jboss.org/browse/AS7-1159
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 7.0.0.CR1
>            Reporter: Darran Lofthouse
>            Assignee: Alexey Loubyansky
>             Fix For: 7.1.0.Alpha1
>
>
> The following NPE occurs if a file is executed without specifying to connect: -
> java.lang.NullPointerException
> 	at org.jboss.as.cli.handlers.batch.BatchRunHandler.doHandle(BatchRunHandler.java:82)
> 	at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:92)
> 	at org.jboss.as.cli.CommandLineMain.processLine(CommandLineMain.java:437)
> 	at org.jboss.as.cli.CommandLineMain.processFile(CommandLineMain.java:363)
> 	at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:257)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.jboss.modules.Module.run(Module.java:270)
> 	at org.jboss.modules.Main.main(Main.java:313)
> However the error that is reported to the end user is "Failed to execute batch: null"
> The following command from the CR1 distro will reproduce: -
>   ./jboss-admin.sh --file=scripts/secure-standalone-mgmt.cli 
> In addition to this it is not possible to specify the address of the native interface to connect to from the command line when using --file, if --connect is specified only the default host and port will be used.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 10:11:23 2011
From: jira-events at lists.jboss.org (Trustin Lee (JIRA))
Date: Mon, 11 Jul 2011 10:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1251) Threads subsystem
 writer generates incorrect XML for unbounded queue thread pool
Message-ID: <735250516.45363.1310393483819.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Threads subsystem writer generates incorrect XML for unbounded queue thread pool
--------------------------------------------------------------------------------

                 Key: AS7-1251
                 URL: https://issues.jboss.org/browse/AS7-1251
             Project: Application Server 7
          Issue Type: Bug
            Reporter: Trustin Lee


{code}
<unbounded-queue-thread-pool name="jgroups">
{code}

is written back as:

{code}
<unbounded-queue-thread-pool blocking="jgroups">
</code>

Hence making the next startup fail.

Similar issue was found and fixed (AS7-233).  We need to check all queue types.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 10:11:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 10:11:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-712) Publish all
 org.jboss.domain.* schemas to http://www.jboss.org/schema/
In-Reply-To: <260965286.28241.1304436318263.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <281290180.45367.1310393484137.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on AS7-712:
--------------------------------------

Yes, I'll do that once we're 100% absolutely positively sure there will be no further changes.

> Publish all org.jboss.domain.* schemas to http://www.jboss.org/schema/
> ----------------------------------------------------------------------
>
>                 Key: AS7-712
>                 URL: https://issues.jboss.org/browse/AS7-712
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Priority: Blocker
>             Fix For: 7.0.0.Final
>
>
> http://community.jboss.org/wiki/JBossDTDs

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 10:11:24 2011
From: jira-events at lists.jboss.org (Trustin Lee (JIRA))
Date: Mon, 11 Jul 2011 10:11:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1251) Threads subsystem
 writer generates incorrect XML for unbounded queue thread pool
In-Reply-To: <735250516.45363.1310393483819.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1449281280.45370.1310393484271.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Trustin Lee updated AS7-1251:
-----------------------------

    Description: 
{code}
<unbounded-queue-thread-pool name="jgroups">
{code}

is written back as:

{code}
<unbounded-queue-thread-pool blocking="jgroups">
{code}

Hence making the next startup fail.

Similar issue was found and fixed (AS7-233).  We need to check all queue types.

  was:
{code}
<unbounded-queue-thread-pool name="jgroups">
{code}

is written back as:

{code}
<unbounded-queue-thread-pool blocking="jgroups">
</code>

Hence making the next startup fail.

Similar issue was found and fixed (AS7-233).  We need to check all queue types.



> Threads subsystem writer generates incorrect XML for unbounded queue thread pool
> --------------------------------------------------------------------------------
>
>                 Key: AS7-1251
>                 URL: https://issues.jboss.org/browse/AS7-1251
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: Trustin Lee
>
> {code}
> <unbounded-queue-thread-pool name="jgroups">
> {code}
> is written back as:
> {code}
> <unbounded-queue-thread-pool blocking="jgroups">
> {code}
> Hence making the next startup fail.
> Similar issue was found and fixed (AS7-233).  We need to check all queue types.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 10:17:23 2011
From: jira-events at lists.jboss.org (Trustin Lee (JIRA))
Date: Mon, 11 Jul 2011 10:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1252) Infinispan subsystem
 writer generates incorrect XML
Message-ID: <1889213554.45389.1310393843924.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Infinispan subsystem writer generates incorrect XML
---------------------------------------------------

                 Key: AS7-1252
                 URL: https://issues.jboss.org/browse/AS7-1252
             Project: Application Server 7
          Issue Type: Bug
            Reporter: Trustin Lee


The following XML configuration:

{code}
        <subsystem xmlns="urn:jboss:domain:infinispan:1.0" default-cache-container="default">
            <cache-container name="default"
                             default-cache="default"
                             listener-executor="infinispan-listener"
                             eviction-executor="infinispan-eviction"
                             replication-queue-executor="infinispan-repl-queue">
                <transport executor="infinispan-transport"/>
                <distributed-cache name="default" start="EAGER" mode="SYNC" />
            </cache-container>
        </subsystem>
        <subsystem xmlns="urn:jboss:domain:datagrid:endpoint:1.0">
            ...
{code}

is written back to:

{code}
        <subsystem xmlns="urn:jboss:domain:infinispan:1.0" default-cache-container="default">
            <cache-container name="default" default-cache="default" listener-executor="infinispan-listener" eviction-executor="infinispan-eviction" replication-queue-executor="infinispan-repl-queue">
                <transport executor="infinispan-transport">
                    <distributed-cache mode="SYNC" name="default" start="EAGER"/>
                </transport>
            </cache-container>
            <subsystem xmlns="urn:jboss:domain:datagrid:endpoint:1.0">
                ...
{code}

making the subsequent startup fail.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 10:17:23 2011
From: jira-events at lists.jboss.org (Trustin Lee (JIRA))
Date: Mon, 11 Jul 2011 10:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1252) Infinispan subsystem
 writer generates incorrect XML
In-Reply-To: <1889213554.45389.1310393843924.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <636851580.45392.1310393843987.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Trustin Lee updated AS7-1252:
-----------------------------

    Affects Version/s: 7.0.0.CR1
          Component/s: Clustering


> Infinispan subsystem writer generates incorrect XML
> ---------------------------------------------------
>
>                 Key: AS7-1252
>                 URL: https://issues.jboss.org/browse/AS7-1252
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.CR1
>            Reporter: Trustin Lee
>
> The following XML configuration:
> {code}
>         <subsystem xmlns="urn:jboss:domain:infinispan:1.0" default-cache-container="default">
>             <cache-container name="default"
>                              default-cache="default"
>                              listener-executor="infinispan-listener"
>                              eviction-executor="infinispan-eviction"
>                              replication-queue-executor="infinispan-repl-queue">
>                 <transport executor="infinispan-transport"/>
>                 <distributed-cache name="default" start="EAGER" mode="SYNC" />
>             </cache-container>
>         </subsystem>
>         <subsystem xmlns="urn:jboss:domain:datagrid:endpoint:1.0">
>             ...
> {code}
> is written back to:
> {code}
>         <subsystem xmlns="urn:jboss:domain:infinispan:1.0" default-cache-container="default">
>             <cache-container name="default" default-cache="default" listener-executor="infinispan-listener" eviction-executor="infinispan-eviction" replication-queue-executor="infinispan-repl-queue">
>                 <transport executor="infinispan-transport">
>                     <distributed-cache mode="SYNC" name="default" start="EAGER"/>
>                 </transport>
>             </cache-container>
>             <subsystem xmlns="urn:jboss:domain:datagrid:endpoint:1.0">
>                 ...
> {code}
> making the subsequent startup fail.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 10:17:24 2011
From: jira-events at lists.jboss.org (Trustin Lee (JIRA))
Date: Mon, 11 Jul 2011 10:17:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1251) Threads subsystem
 writer generates incorrect XML for unbounded queue thread pool
In-Reply-To: <735250516.45363.1310393483819.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <264286258.45424.1310393844930.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Trustin Lee updated AS7-1251:
-----------------------------

    Affects Version/s: 7.0.0.CR1


> Threads subsystem writer generates incorrect XML for unbounded queue thread pool
> --------------------------------------------------------------------------------
>
>                 Key: AS7-1251
>                 URL: https://issues.jboss.org/browse/AS7-1251
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.CR1
>            Reporter: Trustin Lee
>
> {code}
> <unbounded-queue-thread-pool name="jgroups">
> {code}
> is written back as:
> {code}
> <unbounded-queue-thread-pool blocking="jgroups">
> {code}
> Hence making the next startup fail.
> Similar issue was found and fixed (AS7-233).  We need to check all queue types.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 10:19:24 2011
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 11 Jul 2011 10:19:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1234) Hibernate does not
 read/use metadata for orm.xml defined entites
In-Reply-To: <461439061.42234.1310135790589.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1387842673.45446.1310393964311.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar updated AS7-1234:
-----------------------------

    Attachment: module.zip
                webapp-1.0.war


Test module + application.
module.zip should be unziped in modules folder.
webapp then refrences that module via MAINFEST.MF.



> Hibernate does not read/use metadata for orm.xml defined entites
> ----------------------------------------------------------------
>
>                 Key: AS7-1234
>                 URL: https://issues.jboss.org/browse/AS7-1234
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta3, 7.0.0.CR1, 7.0.0.Final, 7.0.1.Final, 7.1.0.Alpha1
>         Environment: windows 7, sql server 2008 r2
>            Reporter: Tomaz Cerar
>            Assignee: Scott Marlow
>         Attachments: module.zip, webapp-1.0.war
>
>
> I have setup where we have "common" entities defined in global lib/module that application(war/ear) in then dependent on.
> Then I declare this entities in orm.xml of my application just by class name.
> for instance:
> {code:xml}
> <entity class="com.company.module.Article"/>
> <entity class="com.company.module.Binary"/>
> <entity class="com.company.module.Category"/>
> {code}
> Up until as7/hibernate 4 this worked with no problems, but now it dies with exception "no id defined on entity Article". If I defined id in orm.xml it then finds id field but fails to find anything that is annotated on classes. 
> It looks like metadata is not read for this classes and hibernate sees them as just plain pojo with no annotations.
> I am guessing that problem has to do something with integration with AS7 that now has jandex index for all annotations...

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 10:21:24 2011
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 11 Jul 2011 10:21:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1234) Hibernate does not
 read/use metadata for orm.xml defined entites
In-Reply-To: <461439061.42234.1310135790589.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1797290866.45470.1310394084303.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar commented on AS7-1234:
----------------------------------

this is full log for jboss start (master build + hiberante 4 beta3) http://pastie.org/2196871

> Hibernate does not read/use metadata for orm.xml defined entites
> ----------------------------------------------------------------
>
>                 Key: AS7-1234
>                 URL: https://issues.jboss.org/browse/AS7-1234
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta3, 7.0.0.CR1, 7.0.0.Final, 7.0.1.Final, 7.1.0.Alpha1
>         Environment: windows 7, sql server 2008 r2
>            Reporter: Tomaz Cerar
>            Assignee: Scott Marlow
>         Attachments: module.zip, webapp-1.0.war
>
>
> I have setup where we have "common" entities defined in global lib/module that application(war/ear) in then dependent on.
> Then I declare this entities in orm.xml of my application just by class name.
> for instance:
> {code:xml}
> <entity class="com.company.module.Article"/>
> <entity class="com.company.module.Binary"/>
> <entity class="com.company.module.Category"/>
> {code}
> Up until as7/hibernate 4 this worked with no problems, but now it dies with exception "no id defined on entity Article". If I defined id in orm.xml it then finds id field but fails to find anything that is annotated on classes. 
> It looks like metadata is not read for this classes and hibernate sees them as just plain pojo with no annotations.
> I am guessing that problem has to do something with integration with AS7 that now has jandex index for all annotations...

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 10:25:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 10:25:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1251) Threads subsystem
 writer generates incorrect XML for unbounded queue thread pool
In-Reply-To: <735250516.45363.1310393483819.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <278008498.45482.1310394323846.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned AS7-1251:
-------------------------------------

    Assignee: Brian Stansberry


> Threads subsystem writer generates incorrect XML for unbounded queue thread pool
> --------------------------------------------------------------------------------
>
>                 Key: AS7-1251
>                 URL: https://issues.jboss.org/browse/AS7-1251
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.CR1
>            Reporter: Trustin Lee
>            Assignee: Brian Stansberry
>
> {code}
> <unbounded-queue-thread-pool name="jgroups">
> {code}
> is written back as:
> {code}
> <unbounded-queue-thread-pool blocking="jgroups">
> {code}
> Hence making the next startup fail.
> Similar issue was found and fixed (AS7-233).  We need to check all queue types.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 10:25:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 10:25:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1240) Allow FS deployment
 scanner to treat deleting deployment content as a trigger for undeploy
In-Reply-To: <1052869189.43293.1310218283650.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <318349715.45485.1310394323976.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry resolved AS7-1240.
-----------------------------------

    Resolution: Done


> Allow FS deployment scanner to treat deleting deployment content as a trigger for undeploy
> ------------------------------------------------------------------------------------------
>
>                 Key: AS7-1240
>                 URL: https://issues.jboss.org/browse/AS7-1240
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Server
>    Affects Versions: 7.0.0.CR1
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 7.0.1.Final
>
>
> Currently you have to delete the .deployed file to trigger an undeploy. FileSystemDeploymentService should also treat deleting the deployment content as a trigger.
> Deleting the content *is the incorrect way to trigger undeployment of an exploded archive.*  It's perfectly fine for a zipped deployment, but for an exploded deployment it removes the content out from under the appserver before the AS has a chance to properly undeploy.
> Still, even though deleting the content as a trigger is the wrong thing to do in the exploded case, it's the more intuitive thing to do in the non-exploded case, and having the AS use it as a trigger in the exploded case doesn't increase the harm. The content is gone; the app is broken, might as well try and undeploy it.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 10:33:23 2011
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 11 Jul 2011 10:33:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-1234)
 Hibernate does not read/use metadata for orm.xml defined entites
In-Reply-To: <461439061.42234.1310135790589.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <643585122.45539.1310394803743.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar edited comment on AS7-1234 at 7/11/11 10:31 AM:
------------------------------------------------------------

this is full log for jboss start (master build + hiberante 4 beta3) http://pastie.org/2196871

code for my "example" can be found here https://github.com/ctomc/Playground/tree/master/as7-1234


      was (Author: ctomc):
    this is full log for jboss start (master build + hiberante 4 beta3) http://pastie.org/2196871
  
> Hibernate does not read/use metadata for orm.xml defined entites
> ----------------------------------------------------------------
>
>                 Key: AS7-1234
>                 URL: https://issues.jboss.org/browse/AS7-1234
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta3, 7.0.0.CR1, 7.0.0.Final, 7.0.1.Final, 7.1.0.Alpha1
>         Environment: windows 7, sql server 2008 r2
>            Reporter: Tomaz Cerar
>            Assignee: Scott Marlow
>         Attachments: module.zip, webapp-1.0.war
>
>
> I have setup where we have "common" entities defined in global lib/module that application(war/ear) in then dependent on.
> Then I declare this entities in orm.xml of my application just by class name.
> for instance:
> {code:xml}
> <entity class="com.company.module.Article"/>
> <entity class="com.company.module.Binary"/>
> <entity class="com.company.module.Category"/>
> {code}
> Up until as7/hibernate 4 this worked with no problems, but now it dies with exception "no id defined on entity Article". If I defined id in orm.xml it then finds id field but fails to find anything that is annotated on classes. 
> It looks like metadata is not read for this classes and hibernate sees them as just plain pojo with no annotations.
> I am guessing that problem has to do something with integration with AS7 that now has jandex index for all annotations...

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 10:37:25 2011
From: jira-events at lists.jboss.org (Jean-Frederic Clere (JIRA))
Date: Mon, 11 Jul 2011 10:37:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1231) Horrible XML
 parsing error reports
In-Reply-To: <51499966.42067.1310132663768.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <189245481.45610.1310395045813.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jean-Frederic Clere commented on AS7-1231:
------------------------------------------

Would be:

09:39:14,132 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC00001: Failed to start service jboss.deployment.unit."basic.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."basic.war".PARSE: Failed to process phase PARSE of deployment "basic.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
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_26]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to parse "/content/basic.war/WEB-INF/jboss-web.xml" at [5,4]
at org.jboss.as.web.deployment.JBossWebParsingDeploymentProcessor.deploy(JBossWebParsingDeploymentProcessor.java:66)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
... 5 more

better? :D

> Horrible XML parsing error reports
> ----------------------------------
>
>                 Key: AS7-1231
>                 URL: https://issues.jboss.org/browse/AS7-1231
>             Project: Application Server 7
>          Issue Type: Quality Risk
>            Reporter: Bill Burke
>            Assignee: Jean-Frederic Clere
>
> If I make a typo in jboss-web.xml (or any other descriptor for that matter) I get really obscure errors that don't help me debug the problem.  (See below).  Each project really needs to 
> 09:39:14,132 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC00001: Failed to start service jboss.deployment.unit."basic.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."basic.war".PARSE: Failed to process phase PARSE of deployment "basic.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
> 	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_26]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
> 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to parse "/content/basic.war/WEB-INF/jboss-web.xml"
> 	at org.jboss.as.web.deployment.JBossWebParsingDeploymentProcessor.deploy(JBossWebParsingDeploymentProcessor.java:66)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
> 	... 5 more
> Caused by: com.ctc.wstx.exc.WstxParsingException: Received non-all-whitespace CHARACTERS or CDATA event in nextTag().
>  at [row,col {unknown-source}]: [5,4]
> 	at com.ctc.wstx.sr.StreamScanner.constructWfcException(StreamScanner.java:606)
> 	at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:479)
> 	at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:464)
> 	at com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1137)
> 	at org.jboss.metadata.parser.jbossweb.ValveMetaDataParser.parse(ValveMetaDataParser.java:45)
> 	at org.jboss.metadata.parser.jbossweb.JBossWebMetaDataParser.parse(JBossWebMetaDataParser.java:155)
> 	at org.jboss.as.web.deployment.JBossWebParsingDeploymentProcessor.deploy(JBossWebParsingDeploymentProcessor.java:64)
> 	... 6 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 10:47:23 2011
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Mon, 11 Jul 2011 10:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1231) Horrible XML
 parsing error reports
In-Reply-To: <51499966.42067.1310132663768.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <953414218.45628.1310395643703.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jason Greene commented on AS7-1231:
-----------------------------------

BTW staxmapper doesn't do anything special like I for some reason thought it did.

The problem is caused when someone does something like this <thing></thing>@#@#%$@$WEF<other></other>. So the error message is actually accurate, it's just obtuse. It could be a bit more human friend/verbose if we implemented something like I thought we did in staxmapper (but do not) where we implement a nextTag which explains what in more detail what went wrong. See

http://download.oracle.com/javase/6/docs/api/javax/xml/stream/XMLStreamReader.html#nextTag()

I like the idea of putting location early.



> Horrible XML parsing error reports
> ----------------------------------
>
>                 Key: AS7-1231
>                 URL: https://issues.jboss.org/browse/AS7-1231
>             Project: Application Server 7
>          Issue Type: Quality Risk
>            Reporter: Bill Burke
>            Assignee: Jean-Frederic Clere
>
> If I make a typo in jboss-web.xml (or any other descriptor for that matter) I get really obscure errors that don't help me debug the problem.  (See below).  Each project really needs to 
> 09:39:14,132 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC00001: Failed to start service jboss.deployment.unit."basic.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."basic.war".PARSE: Failed to process phase PARSE of deployment "basic.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
> 	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_26]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
> 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to parse "/content/basic.war/WEB-INF/jboss-web.xml"
> 	at org.jboss.as.web.deployment.JBossWebParsingDeploymentProcessor.deploy(JBossWebParsingDeploymentProcessor.java:66)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
> 	... 5 more
> Caused by: com.ctc.wstx.exc.WstxParsingException: Received non-all-whitespace CHARACTERS or CDATA event in nextTag().
>  at [row,col {unknown-source}]: [5,4]
> 	at com.ctc.wstx.sr.StreamScanner.constructWfcException(StreamScanner.java:606)
> 	at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:479)
> 	at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:464)
> 	at com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1137)
> 	at org.jboss.metadata.parser.jbossweb.ValveMetaDataParser.parse(ValveMetaDataParser.java:45)
> 	at org.jboss.metadata.parser.jbossweb.JBossWebMetaDataParser.parse(JBossWebMetaDataParser.java:155)
> 	at org.jboss.as.web.deployment.JBossWebParsingDeploymentProcessor.deploy(JBossWebParsingDeploymentProcessor.java:64)
> 	... 6 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 10:55:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 10:55:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1240) Allow FS deployment
 scanner to treat deleting deployment content as a trigger for undeploy
In-Reply-To: <1052869189.43293.1310218283650.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1731980386.45636.1310396123678.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-1240:
----------------------------------

    Fix Version/s: 7.0.0.Final
                       (was: 7.0.1.Final)


> Allow FS deployment scanner to treat deleting deployment content as a trigger for undeploy
> ------------------------------------------------------------------------------------------
>
>                 Key: AS7-1240
>                 URL: https://issues.jboss.org/browse/AS7-1240
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Server
>    Affects Versions: 7.0.0.CR1
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 7.0.0.Final
>
>
> Currently you have to delete the .deployed file to trigger an undeploy. FileSystemDeploymentService should also treat deleting the deployment content as a trigger.
> Deleting the content *is the incorrect way to trigger undeployment of an exploded archive.*  It's perfectly fine for a zipped deployment, but for an exploded deployment it removes the content out from under the appserver before the AS has a chance to properly undeploy.
> Still, even though deleting the content as a trigger is the wrong thing to do in the exploded case, it's the more intuitive thing to do in the non-exploded case, and having the AS use it as a trigger in the exploded case doesn't increase the harm. The content is gone; the app is broken, might as well try and undeploy it.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 11:11:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 11:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1252) Infinispan subsystem
 writer generates incorrect XML
In-Reply-To: <1889213554.45389.1310393843924.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1817402105.45685.1310397083917.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned AS7-1252:
-------------------------------------

    Assignee: Brian Stansberry


> Infinispan subsystem writer generates incorrect XML
> ---------------------------------------------------
>
>                 Key: AS7-1252
>                 URL: https://issues.jboss.org/browse/AS7-1252
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.CR1
>            Reporter: Trustin Lee
>            Assignee: Brian Stansberry
>
> The following XML configuration:
> {code}
>         <subsystem xmlns="urn:jboss:domain:infinispan:1.0" default-cache-container="default">
>             <cache-container name="default"
>                              default-cache="default"
>                              listener-executor="infinispan-listener"
>                              eviction-executor="infinispan-eviction"
>                              replication-queue-executor="infinispan-repl-queue">
>                 <transport executor="infinispan-transport"/>
>                 <distributed-cache name="default" start="EAGER" mode="SYNC" />
>             </cache-container>
>         </subsystem>
>         <subsystem xmlns="urn:jboss:domain:datagrid:endpoint:1.0">
>             ...
> {code}
> is written back to:
> {code}
>         <subsystem xmlns="urn:jboss:domain:infinispan:1.0" default-cache-container="default">
>             <cache-container name="default" default-cache="default" listener-executor="infinispan-listener" eviction-executor="infinispan-eviction" replication-queue-executor="infinispan-repl-queue">
>                 <transport executor="infinispan-transport">
>                     <distributed-cache mode="SYNC" name="default" start="EAGER"/>
>                 </transport>
>             </cache-container>
>             <subsystem xmlns="urn:jboss:domain:datagrid:endpoint:1.0">
>                 ...
> {code}
> making the subsequent startup fail.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 11:15:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 11:15:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1253) Package
 org.jboss.as.clustering has classes in multiple modules
Message-ID: <768258867.45718.1310397323909.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Package org.jboss.as.clustering has classes in multiple modules
---------------------------------------------------------------

                 Key: AS7-1253
                 URL: https://issues.jboss.org/browse/AS7-1253
             Project: Application Server 7
          Issue Type: Bug
          Components: Clustering
            Reporter: Brian Stansberry
            Assignee: Paul Ferraro
             Fix For: 7.0.1.Final


Package splitting is verbotten in AS 7, even if all the jars are meant to be used as a unit.

This is probably the result of the split of the clustering module into multiple pieces.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 11:21:32 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 11:21:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1236) copied lib directory
 in the deployments directory results in deployment
In-Reply-To: <1720824389.42997.1310155524058.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1598602088.45724.1310397692414.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-1236:
----------------------------------

    Fix Version/s: 7.0.0.Final
                       (was: 7.0.1.Final)


> copied lib directory in the deployments directory results in deployment
> -----------------------------------------------------------------------
>
>                 Key: AS7-1236
>                 URL: https://issues.jboss.org/browse/AS7-1236
>             Project: Application Server 7
>          Issue Type: Feature Request
>         Environment: JBoss AS 7 CR 1
>            Reporter: Jim Tyrrell
>            Assignee: Brian Stansberry
>             Fix For: 7.0.0.Final
>
>         Attachments: Sample.war
>
>
> Having an existing zipped up war file, and then unzipping it in the deployment directory, creates a lib directory that has a bunch of jar files in it.  It appears that these jar files in this lib directory are marked as .failed as they are tried to be deployed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 11:21:32 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 11:21:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1214) Using specific
 socket-binding does not override bind address for
 pbcast.STREAMING_STATE_TRANSFER
In-Reply-To: <1342587320.38022.1309976244373.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1234006651.45728.1310397692520.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-1214:
----------------------------------

    Fix Version/s: 7.0.0.Final
                       (was: 7.1.0.Alpha1)
                       (was: 7.0.1.Final)


> Using specific socket-binding does not override bind address for pbcast.STREAMING_STATE_TRANSFER
> ------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1214
>                 URL: https://issues.jboss.org/browse/AS7-1214
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.CR1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 7.0.0.Final
>
>
> You should be able to override the bind_addr and bind_port by defining a specific socket-binding, however, this doesn't work.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 11:23:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 11:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1215)
 pbcast.STREAMING_STATE_TRANSFER should default to use the bind address of
 the transport
In-Reply-To: <951060406.38063.1309976723720.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1220274717.45731.1310397803626.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-1215:
----------------------------------

    Fix Version/s: 7.0.0.Final
                       (was: 7.1.0.Alpha1)
                       (was: 7.0.1.Final)


> pbcast.STREAMING_STATE_TRANSFER should default to use the bind address of the transport
> ---------------------------------------------------------------------------------------
>
>                 Key: AS7-1215
>                 URL: https://issues.jboss.org/browse/AS7-1215
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 7.0.0.Final
>
>
> Currently, pbcast.STREAMING_STATE_TRANSFER uses an auto-detected bind address, if none was specified.  It should default to the bind address or the transport.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 11:27:23 2011
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Mon, 11 Jul 2011 11:27:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (AS7-1195) Failure to load
 login-module should be reported as WARNING instead of TRACE
In-Reply-To: <604271086.36476.1309909524203.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2027635934.45748.1310398043884.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Marcus Moyses reopened AS7-1195:
--------------------------------



> Failure to load login-module should be reported as WARNING instead of TRACE
> ---------------------------------------------------------------------------
>
>                 Key: AS7-1195
>                 URL: https://issues.jboss.org/browse/AS7-1195
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Security
>    Affects Versions: 7.0.0.CR1
>         Environment: java-6-sun-1.6.0.24
> Linux ubuntu 
>            Reporter: Bruno Vernay
>            Assignee: Marcus Moyses
>             Fix For: 7.0.1.Final
>
>
> An error in standalone.xml :
> <security-domains>              
>  <security-domain ...>
>   <authentication>
>    <login-module code="database" flag="required">
> is reported in TRACE: 
> TRACE [org.jboss.security.authentication.JBossCachedAuthenticationManager] (http--127.0.0.1-8080-1) Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: database from [Module "deployment.jboss-as-login.war:main" from Service Module Loader]
> It makes it difficult to spot the error. 
> Would be easier if it was reported as a WARNING, specially since it is "required"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 11:33:23 2011
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 11 Jul 2011 11:33:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1225) jboss-admin.sh fails
 to exit when run in single command mode
In-Reply-To: <627196052.40655.1310071463653.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <364415175.45769.1310398403923.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Kabir Khan resolved AS7-1225.
-----------------------------

    Fix Version/s: 7.0.0.Final
       Resolution: Done


> jboss-admin.sh fails to exit when run in single command mode
> ------------------------------------------------------------
>
>                 Key: AS7-1225
>                 URL: https://issues.jboss.org/browse/AS7-1225
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 7.0.0.Final
>            Reporter: Scott Stark
>            Assignee: Kabir Khan
>             Fix For: 7.0.0.Final
>
>         Attachments: CommandLineMain.java.diff
>
>
> This seems to be a new behavior, but regardless it is a problem that breaks other frameworks that call out to the command line shell with a single command and expect it to return. Currently it fails to exit, and callers hang. This is true both in the case of the server running with a management interface, and when one is missing:
> [269](ironmaiden:bin) > ./jboss-admin.sh --connect command=:shutdown
> Connected to standalone controller at localhost:9999
> Communication error: Channel closed
> Closed connection to localhost:9999
> ^C
> [270](ironmaiden:bin) > ./jboss-admin.sh --connect command=:shutdown
> The controller is not available at localhost:9999
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> ^C
> When running a mode where the commands to run are from a file or command line, that is, non-interactive mode, the cli should exit with a status.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 11:48:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 11:48:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1252) Infinispan subsystem
 writer generates incorrect XML
In-Reply-To: <1889213554.45389.1310393843924.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1822462899.45874.1310399303859.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry resolved AS7-1252.
-----------------------------------

    Fix Version/s: 7.0.0.Final
       Resolution: Done


> Infinispan subsystem writer generates incorrect XML
> ---------------------------------------------------
>
>                 Key: AS7-1252
>                 URL: https://issues.jboss.org/browse/AS7-1252
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.CR1
>            Reporter: Trustin Lee
>            Assignee: Brian Stansberry
>             Fix For: 7.0.0.Final
>
>
> The following XML configuration:
> {code}
>         <subsystem xmlns="urn:jboss:domain:infinispan:1.0" default-cache-container="default">
>             <cache-container name="default"
>                              default-cache="default"
>                              listener-executor="infinispan-listener"
>                              eviction-executor="infinispan-eviction"
>                              replication-queue-executor="infinispan-repl-queue">
>                 <transport executor="infinispan-transport"/>
>                 <distributed-cache name="default" start="EAGER" mode="SYNC" />
>             </cache-container>
>         </subsystem>
>         <subsystem xmlns="urn:jboss:domain:datagrid:endpoint:1.0">
>             ...
> {code}
> is written back to:
> {code}
>         <subsystem xmlns="urn:jboss:domain:infinispan:1.0" default-cache-container="default">
>             <cache-container name="default" default-cache="default" listener-executor="infinispan-listener" eviction-executor="infinispan-eviction" replication-queue-executor="infinispan-repl-queue">
>                 <transport executor="infinispan-transport">
>                     <distributed-cache mode="SYNC" name="default" start="EAGER"/>
>                 </transport>
>             </cache-container>
>             <subsystem xmlns="urn:jboss:domain:datagrid:endpoint:1.0">
>                 ...
> {code}
> making the subsequent startup fail.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 11:48:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 11:48:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1251) Threads subsystem
 writer generates incorrect XML for unbounded queue thread pool
In-Reply-To: <735250516.45363.1310393483819.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1697572195.45881.1310399304015.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry resolved AS7-1251.
-----------------------------------

    Fix Version/s: 7.0.0.Final
       Resolution: Done


> Threads subsystem writer generates incorrect XML for unbounded queue thread pool
> --------------------------------------------------------------------------------
>
>                 Key: AS7-1251
>                 URL: https://issues.jboss.org/browse/AS7-1251
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.CR1
>            Reporter: Trustin Lee
>            Assignee: Brian Stansberry
>             Fix For: 7.0.0.Final
>
>
> {code}
> <unbounded-queue-thread-pool name="jgroups">
> {code}
> is written back as:
> {code}
> <unbounded-queue-thread-pool blocking="jgroups">
> {code}
> Hence making the next startup fail.
> Similar issue was found and fixed (AS7-233).  We need to check all queue types.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 12:14:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 11 Jul 2011 12:14:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1241) Async logger without
 subhandler prevents server startup
In-Reply-To: <1128401256.43344.1310243303692.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1318546153.46059.1310400863967.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd resolved AS7-1241.
------------------------------

    Fix Version/s: 7.1.0.Alpha1
       Resolution: Done


> Async logger without subhandler prevents server startup
> -------------------------------------------------------
>
>                 Key: AS7-1241
>                 URL: https://issues.jboss.org/browse/AS7-1241
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.1.0.Alpha1
>            Reporter: Stan Silvert
>            Assignee: David Lloyd
>             Fix For: 7.1.0.Alpha1
>
>
> <async-handler name="ASYNC">
>    <level name="INFO"/>
>    <queue-length value="1024"/>
>    <overflow-action value="BLOCK"/> 
>    <subhandlers>
>    </subhandlers>               
> </async-handler>
> 16:26:01,926 ERROR [org.jboss.as.controller] Operation ("add") failed - address: ([
>     ("subsystem" => "logging"),
>     ("async-handler" => "ASYNC")
> ]): java.lang.IllegalArgumentException
>         at org.jboss.dmr.ModelValue.asList(ModelValue.java:128)
>         at org.jboss.dmr.ModelNode.asList(ModelNode.java:1096)
>         at org.jboss.as.logging.AsyncHandlerAdd.performRuntime(AsyncHandlerAdd.java:67)
>         at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:47)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:53)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:53)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:53)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:53)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:53)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.server.DeployerChainAddHandler.execute(DeployerChainAddHandler.java:105)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.txn.TransactionSubsystemAdd.execute(TransactionSubsystemAdd.java:272)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.security.SecuritySubsystemAdd.execute(SecuritySubsystemAdd.java:300)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.threads.BoundedQueueThreadPoolAdd.execute(BoundedQueueThreadPoolAdd.java:133)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.threads.BoundedQueueThreadPoolAdd.execute(BoundedQueueThreadPoolAdd.java:133)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.logging.RootLoggerAdd.execute(RootLoggerAdd.java:94)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.operations.global.WriteAttributeHandlers$WriteAttributeOperationHandler.modelChanged(WriteAttributeHandlers.java:114)
>         at org.jboss.as.controller.operations.global.WriteAttributeHandlers$WriteAttributeOperationHandler.execute(WriteAttributeHandlers.java:81)
>         at org.jboss.as.controller.operations.global.GlobalOperationHandlers$WriteAttributeHandler.execute(GlobalOperationHandlers.java:395)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:59)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl$BootStepHandler.execute(ModelControllerImpl.java:180)
>         at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
>         at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
>         at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
>         at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:143)
>         at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:109)
>         at org.jboss.as.server.ServerService.boot(ServerService.java:204)
>         at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:104)
>         at org.jboss.as.server.ServerService.boot(ServerService.java:193)
>         at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:83)
>         at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]
> 16:26:02,236 INFO  [org.jboss.as.controller] Service status report
>    New missing/unsatisfied dependencies:
>       service jboss.network.management (missing)
>       service jboss.remoting.endpoint (missing)
> 16:26:02,249 INFO  [org.jboss.as.controller] Service status report
>    Newly corrected services:
>       service jboss.network.management (no longer required)
>       service jboss.remoting.endpoint (no longer required)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 12:25:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 11 Jul 2011 12:25:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1185) Classpath issue
 breaks localization in Hibernate Validator
In-Reply-To: <1248663250.34872.1309851383660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <193383020.46094.1310401523909.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on AS7-1185:
-----------------------------------

The root of the .ear is not available in the classpath. Move those .properties to the .war/WEB-INF/classes folder (if you need them in the web layer) or to the root of the ejb jar file (if it's required in the EJB module).


> Classpath issue breaks localization in Hibernate Validator
> ----------------------------------------------------------
>
>                 Key: AS7-1185
>                 URL: https://issues.jboss.org/browse/AS7-1185
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Modules
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>         Attachments: testcase-src.zip, testcase.ear
>
>
> If you want Hibernate Validator to produce internationalized / localized messages you need properties files like e.g. ValidatorMessages_en.properties or ValidatorMessages_de.properties. These properties files must be in the Classpath. Thus if you need them in an EJB module, they are placed in the root directory of the EAR.
> According to the language the right file is picked up, and the right hand side has the localized message belonging to the key on the left hand side. However, if no key is found or if the properties file isn't found, then the localized message is just "{key}" aka the template message.
> I'll attach a testcase to reproduce this issue that ValidatorMessage_xx.properties isn't found in the Classpath.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 12:25:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 11 Jul 2011 12:25:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1185) Classpath issue
 breaks localization in Hibernate Validator
In-Reply-To: <1248663250.34872.1309851383660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2068364402.46112.1310401524576.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai updated AS7-1185:
------------------------------

    Component/s: EE
                     (was: Modules)


> Classpath issue breaks localization in Hibernate Validator
> ----------------------------------------------------------
>
>                 Key: AS7-1185
>                 URL: https://issues.jboss.org/browse/AS7-1185
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>         Attachments: testcase-src.zip, testcase.ear
>
>
> If you want Hibernate Validator to produce internationalized / localized messages you need properties files like e.g. ValidatorMessages_en.properties or ValidatorMessages_de.properties. These properties files must be in the Classpath. Thus if you need them in an EJB module, they are placed in the root directory of the EAR.
> According to the language the right file is picked up, and the right hand side has the localized message belonging to the key on the left hand side. However, if no key is found or if the properties file isn't found, then the localized message is just "{key}" aka the template message.
> I'll attach a testcase to reproduce this issue that ValidatorMessage_xx.properties isn't found in the Classpath.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 13:19:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Mon, 11 Jul 2011 13:19:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1185) Classpath issue
 breaks localization in Hibernate Validator
In-Reply-To: <1248663250.34872.1309851383660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <751214786.46232.1310404763721.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Juergen Zimmermann commented on AS7-1185:
-----------------------------------------

Hmm, but I need these properties files in the EJB *AND* in the web module. If the EAR root isn't in the CLASSPATH anymore, I'd consider this as a serious regression.

> Classpath issue breaks localization in Hibernate Validator
> ----------------------------------------------------------
>
>                 Key: AS7-1185
>                 URL: https://issues.jboss.org/browse/AS7-1185
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>         Attachments: testcase-src.zip, testcase.ear
>
>
> If you want Hibernate Validator to produce internationalized / localized messages you need properties files like e.g. ValidatorMessages_en.properties or ValidatorMessages_de.properties. These properties files must be in the Classpath. Thus if you need them in an EJB module, they are placed in the root directory of the EAR.
> According to the language the right file is picked up, and the right hand side has the localized message belonging to the key on the left hand side. However, if no key is found or if the properties file isn't found, then the localized message is just "{key}" aka the template message.
> I'll attach a testcase to reproduce this issue that ValidatorMessage_xx.properties isn't found in the Classpath.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 13:21:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 11 Jul 2011 13:21:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1185) Classpath issue
 breaks localization in Hibernate Validator
In-Reply-To: <1248663250.34872.1309851383660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <443319033.46247.1310404884622.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on AS7-1185:
-----------------------------------

EE never mandated the .ear root to be in the classpath. It was just a JBoss specific way which was deprecated in AS5 (there was a flag to change the behaviour). 

If you want it available in both EJB and web, then package it at the root of a jar and place that jar in the .ear/lib folder. That should work. If it doesn't, then let us know.


> Classpath issue breaks localization in Hibernate Validator
> ----------------------------------------------------------
>
>                 Key: AS7-1185
>                 URL: https://issues.jboss.org/browse/AS7-1185
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>         Attachments: testcase-src.zip, testcase.ear
>
>
> If you want Hibernate Validator to produce internationalized / localized messages you need properties files like e.g. ValidatorMessages_en.properties or ValidatorMessages_de.properties. These properties files must be in the Classpath. Thus if you need them in an EJB module, they are placed in the root directory of the EAR.
> According to the language the right file is picked up, and the right hand side has the localized message belonging to the key on the left hand side. However, if no key is found or if the properties file isn't found, then the localized message is just "{key}" aka the template message.
> I'll attach a testcase to reproduce this issue that ValidatorMessage_xx.properties isn't found in the Classpath.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 13:58:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Mon, 11 Jul 2011 13:58:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1185) Classpath issue
 breaks localization in Hibernate Validator
In-Reply-To: <1248663250.34872.1309851383660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <402970272.46306.1310407103784.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Juergen Zimmermann commented on AS7-1185:
-----------------------------------------

OK, I wasn't aware that the .ear root inside the classpath was JBoss specific. I understand that this feature is gone.

Using a JAR just containing the .properties files works.

Perhaps you should add this migration problem to a migration FAQ or something like that.

> Classpath issue breaks localization in Hibernate Validator
> ----------------------------------------------------------
>
>                 Key: AS7-1185
>                 URL: https://issues.jboss.org/browse/AS7-1185
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>         Attachments: testcase-src.zip, testcase.ear
>
>
> If you want Hibernate Validator to produce internationalized / localized messages you need properties files like e.g. ValidatorMessages_en.properties or ValidatorMessages_de.properties. These properties files must be in the Classpath. Thus if you need them in an EJB module, they are placed in the root directory of the EAR.
> According to the language the right file is picked up, and the right hand side has the localized message belonging to the key on the left hand side. However, if no key is found or if the properties file isn't found, then the localized message is just "{key}" aka the template message.
> I'll attach a testcase to reproduce this issue that ValidatorMessage_xx.properties isn't found in the Classpath.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 13:58:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 11 Jul 2011 13:58:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-473) Correctly implement
 graceful shutdown for EE components including EJBs
In-Reply-To: <1499375371.14350.1301580398039.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <92393229.46309.1310407103958.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd updated AS7-473:
----------------------------

        Summary: Correctly implement graceful shutdown for EE components including EJBs  (was: On component stop, destroy all instances)
    Description: This may entail forcibly destroying or passivating components.  Or not.  Gather requirements for each component type and work from there.  (was: This will cause all outstanding component destroy lifecycle methods to be invoked when the component is stopped.)
    Component/s: EJB


Updated summary and description for accuracy.

> Correctly implement graceful shutdown for EE components including EJBs
> ----------------------------------------------------------------------
>
>                 Key: AS7-473
>                 URL: https://issues.jboss.org/browse/AS7-473
>             Project: Application Server 7
>          Issue Type: Task
>          Components: EE, EJB
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 7.1.0.Alpha1
>
>
> This may entail forcibly destroying or passivating components.  Or not.  Gather requirements for each component type and work from there.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 14:04:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 14:04:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-295) allows to have
 a "prefered" JBoss server to be picked first if its available
In-Reply-To: <2141283931.41780.1310127331489.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1440321383.46322.1310407463665.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned JBCLUSTER-295:
------------------------------------------

    Assignee:     (was: Brian Stansberry)


Unassigning from myself as I'm no longer doing much clustering development.

> allows to have a "prefered" JBoss server to be picked first if its available
> ----------------------------------------------------------------------------
>
>                 Key: JBCLUSTER-295
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-295
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: HA-Client
>    Affects Versions: HA-Client 1.1.1.GA
>         Environment: all
>            Reporter: Tom Fonteyne
>            Priority: Minor
>              Labels: jboss
>         Attachments: Preferred.java, PreferredRoundRobin.java
>
>
> the scenario consists of a front loadbalancer to a number of Tomcat (or I guess Apache) instances which act as front end to a jboss cluster.
> Each 'front' (tomcat) and 'back' (jboss)  lives as a pair on a single machine.
> The idea is: have the 'front' always contact the local (preferred) 'back' ... and only contact one of the other jboss instances (other boxex) if the local one is not available.
> Attached is proposed code that accomplishes this

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 14:08:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 14:08:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCLUSTER-11) Unified
 clustering configuration and management
Message-ID: <64138388.46326.1310407703882.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry resolved JBCLUSTER-11.
---------------------------------------

    Resolution: Out of Date


> Unified clustering configuration and management
> -----------------------------------------------
>
>                 Key: JBCLUSTER-11
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-11
>             Project: JBoss Clustering
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>            Assignee: Brian Stansberry
>            Priority: Blocker
>             Fix For: Legacy
>
>   Original Estimate: 12 weeks
>  Remaining Estimate: 12 weeks
>
> Will need a more unified management frontend for the new clustering:
> 1. Unified JGroups MBean to configure the channel running inside the JBoss AS.
> 2. Unified JBossCache configuration to select cache instance used for http session, SFSB, entity, and others.
> 3. Unified clustering web console.
> This issue is a duplicate of JBAS-2960.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 14:08:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 14:08:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCLUSTER-117) Clustered
 deployments using the Profile Service
Message-ID: <323001746.46330.1310407704098.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry resolved JBCLUSTER-117.
----------------------------------------

    Resolution: Out of Date


> Clustered deployments using the Profile Service
> -----------------------------------------------
>
>                 Key: JBCLUSTER-117
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-117
>             Project: JBoss Clustering
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Blocker
>             Fix For: Legacy
>
>
> Basic farmed and singleton deployments using microcontainer services (Profile Service, Virtual Deployment Framework).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 14:16:24 2011
From: jira-events at lists.jboss.org (Tarley Lana (JIRA))
Date: Mon, 11 Jul 2011 14:16:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3125) Including
 compression support (gzip) to optimize network traffic between server and
 agent
Message-ID: <1702273616.46339.1310408184473.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Including compression support (gzip) to optimize network traffic between server and agent
-----------------------------------------------------------------------------------------

                 Key: JBRULES-3125
                 URL: https://issues.jboss.org/browse/JBRULES-3125
             Project: Drools
          Issue Type: Patch
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.1.1.FINAL
         Environment: drools-5.1.1-guvnor-standalone, jboss-4.2.3.GA
            Reporter: Tarley Lana
            Assignee: Mark Proctor


This patch makes the class "org.drools.io.impl.UrlResource" support the download of compressed rules. Below are the settings required to enable transmission of compressed rules over the network:

SERVER SIDE

1) In this example I used the "drools-5.1.1-guvnor-standalone" as a rule base;
2) Include the following line in the file "{JBOSS-HOME}\server\default\deploy\jboss-web.deployer\server.xml" to enable compression of the rules:

<Connector port="8080" address="${jboss.bind.address}" 
		maxThreads="250" maxHttpHeaderSize="8192" 
		emptySessionPath="true" protocol="HTTP/1.1" 
		enableLookups="false" redirectPort="8443" acceptCount="100" 
		connectionTimeout="20000" disableUploadTimeout="true" compression="force"
		compressableMimeType="application/x-download" 
		compressionMinSize="100"/>

CLIENT SIDE
1) Set the "ChangeSet.xml" for the rules of the server as the example below:

<change-set xmlns='http://drools.org/drools-5.0/change-set'
xmlns:xs='http://www.w3.org/2001/XMLSchema-instance'
	xs:schemaLocation='http://drools.org/drools-5.0/change-set  http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-api/src/main/resources/change-set-1.0.0.xsd' >
<add>
   <!-- ARKHI / Rackspace -->
   <resource source='http://127.0.0.1:8080/drools-guvnor/org.drools.guvnor.Guvnor/package/araujo.ecf/LATEST'
 type='PKG' basicAuthentication='enabled' username='ecf' password='senha'/>
</add>
</change-set>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 14:18:23 2011
From: jira-events at lists.jboss.org (Tarley Lana (JIRA))
Date: Mon, 11 Jul 2011 14:18:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-3125) Including
 compression support (gzip) to optimize network traffic between server and
 agent
In-Reply-To: <1702273616.46339.1310408184473.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <7618172.46343.1310408303653.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Tarley Lana updated JBRULES-3125:
---------------------------------

    Attachment: patch.txt


> Including compression support (gzip) to optimize network traffic between server and agent
> -----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3125
>                 URL: https://issues.jboss.org/browse/JBRULES-3125
>             Project: Drools
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.1.1.FINAL
>         Environment: drools-5.1.1-guvnor-standalone, jboss-4.2.3.GA
>            Reporter: Tarley Lana
>            Assignee: Mark Proctor
>              Labels: Compress, Compressed
>         Attachments: patch.txt
>
>
> This patch makes the class "org.drools.io.impl.UrlResource" support the download of compressed rules. Below are the settings required to enable transmission of compressed rules over the network:
> SERVER SIDE
> 1) In this example I used the "drools-5.1.1-guvnor-standalone" as a rule base;
> 2) Include the following line in the file "{JBOSS-HOME}\server\default\deploy\jboss-web.deployer\server.xml" to enable compression of the rules:
> <Connector port="8080" address="${jboss.bind.address}" 
> 		maxThreads="250" maxHttpHeaderSize="8192" 
> 		emptySessionPath="true" protocol="HTTP/1.1" 
> 		enableLookups="false" redirectPort="8443" acceptCount="100" 
> 		connectionTimeout="20000" disableUploadTimeout="true" compression="force"
> 		compressableMimeType="application/x-download" 
> 		compressionMinSize="100"/>
> CLIENT SIDE
> 1) Set the "ChangeSet.xml" for the rules of the server as the example below:
> <change-set xmlns='http://drools.org/drools-5.0/change-set'
> xmlns:xs='http://www.w3.org/2001/XMLSchema-instance'
> 	xs:schemaLocation='http://drools.org/drools-5.0/change-set  http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-api/src/main/resources/change-set-1.0.0.xsd' >
> <add>
>    <!-- ARKHI / Rackspace -->
>    <resource source='http://127.0.0.1:8080/drools-guvnor/org.drools.guvnor.Guvnor/package/araujo.ecf/LATEST'
>  type='PKG' basicAuthentication='enabled' username='ecf' password='senha'/>
> </add>
> </change-set>

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 15:02:23 2011
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Mon, 11 Jul 2011 15:02:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1247) Messaging
 Configuration not support all setings defined in jboss-messaging.xsd schema
 file.
In-Reply-To: <38984762.44637.1310371103789.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2088697360.46388.1310410943783.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Clebert Suconic updated AS7-1247:
---------------------------------

           Assignee: Andy Taylor  (was: Clebert Suconic)
    Forum Reference: http://community.jboss.org/thread/168963  (was: http://community.jboss.org/thread/168963)


> Messaging Configuration not support all setings defined in jboss-messaging.xsd schema file.
> -------------------------------------------------------------------------------------------
>
>                 Key: AS7-1247
>                 URL: https://issues.jboss.org/browse/AS7-1247
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 7.0.0.CR1
>         Environment: Windows 7 x64
> Java 1.6.25 x64
> JBoss 7.0.0 CR1 - standalone-preview
>            Reporter: Tomaz Zupan
>            Assignee: Andy Taylor
>              Labels: as7, configuration, jboss, messaging
>         Attachments: standalone-preview.xml
>
>
> Only settings included in standalone-preview.xml configuration file are supported. If some other settings from jboss-messaging.xsd schema file are included,  org.jboss.as.controller.persistence.ConfigurationPersistenceException exception is thrown while the JBoss server is starting.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 15:14:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 11 Jul 2011 15:14:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1185) Classpath issue
 breaks localization in Hibernate Validator
In-Reply-To: <1248663250.34872.1309851383660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <534146725.46409.1310411663724.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on AS7-1185:
-----------------------------------

Thanks for testing and confirming that it works.

{quote}
Perhaps you should add this migration problem to a migration FAQ or something like that.
{quote}
Yes, this would make sense in the classloading article for AS7. I'll add some lines about this, tomorrow.

Closing this JIRA.


> Classpath issue breaks localization in Hibernate Validator
> ----------------------------------------------------------
>
>                 Key: AS7-1185
>                 URL: https://issues.jboss.org/browse/AS7-1185
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>         Attachments: testcase-src.zip, testcase.ear
>
>
> If you want Hibernate Validator to produce internationalized / localized messages you need properties files like e.g. ValidatorMessages_en.properties or ValidatorMessages_de.properties. These properties files must be in the Classpath. Thus if you need them in an EJB module, they are placed in the root directory of the EAR.
> According to the language the right file is picked up, and the right hand side has the localized message belonging to the key on the left hand side. However, if no key is found or if the properties file isn't found, then the localized message is just "{key}" aka the template message.
> I'll attach a testcase to reproduce this issue that ValidatorMessage_xx.properties isn't found in the Classpath.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 15:14:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 11 Jul 2011 15:14:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-1185) Classpath issue breaks
 localization in Hibernate Validator
In-Reply-To: <1248663250.34872.1309851383660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1039267487.46413.1310411663833.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai closed AS7-1185.
-----------------------------

      Assignee: jaikiran pai
    Resolution: Rejected


> Classpath issue breaks localization in Hibernate Validator
> ----------------------------------------------------------
>
>                 Key: AS7-1185
>                 URL: https://issues.jboss.org/browse/AS7-1185
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: jaikiran pai
>         Attachments: testcase-src.zip, testcase.ear
>
>
> If you want Hibernate Validator to produce internationalized / localized messages you need properties files like e.g. ValidatorMessages_en.properties or ValidatorMessages_de.properties. These properties files must be in the Classpath. Thus if you need them in an EJB module, they are placed in the root directory of the EAR.
> According to the language the right file is picked up, and the right hand side has the localized message belonging to the key on the left hand side. However, if no key is found or if the properties file isn't found, then the localized message is just "{key}" aka the template message.
> I'll attach a testcase to reproduce this issue that ValidatorMessage_xx.properties isn't found in the Classpath.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 15:21:23 2011
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Mon, 11 Jul 2011 15:21:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2951) regression:
 cannot compile return value "(java.lang.Object.class)"
In-Reply-To: <774445093.21798.1302601293046.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1482434523.46419.1310412083761.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara commented on JBRULES-2951:
-----------------------------------------

If I'm not mistaken, at the moment Class constants in the LHS must not be specified with the trailing ".class"

> regression: cannot compile return value "(java.lang.Object.class)"
> ------------------------------------------------------------------
>
>                 Key: JBRULES-2951
>                 URL: https://issues.jboss.org/browse/JBRULES-2951
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler
>    Affects Versions: 5.2.0.M2
>            Reporter: Wolfgang Laun
>            Assignee: Mark Proctor
>            Priority: Critical
>
> The rule below compiled with a version build from HEAD on February 10, 2011. But now: 
> Unable to Analyse Expression target == source || target == (java.lang.Object.class):
> [Error: Failed to compile: 2 compilation error(s): 
>  - (1,32) unable to resolve method using strict-mode: ex10.Assignment.java()
>  - (1,32) unqualified type in strict mode for: java]
> [Near : {... target == source || target == (java.lang.Object.class) ....}]
>                                             ^
> [Line: 1, Column: 32] : [Rule name='SameOrObjectIsAssignable']
> ALSO please note that the line number is way off.
> rule SameOrObjectIsAssignable
> when
>     $a: Assignment( $t: target, target == source  || target == (java.lang.Object.class) )
> then
>     System.out.println( $a.toString() + " is OK. " );
>     retract( $a.getOriginal() );
> end

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 15:23:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 11 Jul 2011 15:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (AS7-1185) Classpath issue
 breaks localization in Hibernate Validator
In-Reply-To: <1248663250.34872.1309851383660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <661695831.46429.1310412203923.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai reopened AS7-1185:
-------------------------------



Re-opening to add forum reference


> Classpath issue breaks localization in Hibernate Validator
> ----------------------------------------------------------
>
>                 Key: AS7-1185
>                 URL: https://issues.jboss.org/browse/AS7-1185
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: jaikiran pai
>         Attachments: testcase-src.zip, testcase.ear
>
>
> If you want Hibernate Validator to produce internationalized / localized messages you need properties files like e.g. ValidatorMessages_en.properties or ValidatorMessages_de.properties. These properties files must be in the Classpath. Thus if you need them in an EJB module, they are placed in the root directory of the EAR.
> According to the language the right file is picked up, and the right hand side has the localized message belonging to the key on the left hand side. However, if no key is found or if the properties file isn't found, then the localized message is just "{key}" aka the template message.
> I'll attach a testcase to reproduce this issue that ValidatorMessage_xx.properties isn't found in the Classpath.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 15:25:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 11 Jul 2011 15:25:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1185) Classpath issue
 breaks localization in Hibernate Validator
In-Reply-To: <1248663250.34872.1309851383660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1402577797.46435.1310412323888.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai updated AS7-1185:
------------------------------

    Forum Reference: http://community.jboss.org/thread/169225?tstart=0


> Classpath issue breaks localization in Hibernate Validator
> ----------------------------------------------------------
>
>                 Key: AS7-1185
>                 URL: https://issues.jboss.org/browse/AS7-1185
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: jaikiran pai
>         Attachments: testcase-src.zip, testcase.ear
>
>
> If you want Hibernate Validator to produce internationalized / localized messages you need properties files like e.g. ValidatorMessages_en.properties or ValidatorMessages_de.properties. These properties files must be in the Classpath. Thus if you need them in an EJB module, they are placed in the root directory of the EAR.
> According to the language the right file is picked up, and the right hand side has the localized message belonging to the key on the left hand side. However, if no key is found or if the properties file isn't found, then the localized message is just "{key}" aka the template message.
> I'll attach a testcase to reproduce this issue that ValidatorMessage_xx.properties isn't found in the Classpath.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 15:25:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 11 Jul 2011 15:25:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-1185) Classpath issue breaks
 localization in Hibernate Validator
In-Reply-To: <1248663250.34872.1309851383660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <972764558.46441.1310412324014.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai closed AS7-1185.
-----------------------------

    Resolution: Rejected


> Classpath issue breaks localization in Hibernate Validator
> ----------------------------------------------------------
>
>                 Key: AS7-1185
>                 URL: https://issues.jboss.org/browse/AS7-1185
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: jaikiran pai
>         Attachments: testcase-src.zip, testcase.ear
>
>
> If you want Hibernate Validator to produce internationalized / localized messages you need properties files like e.g. ValidatorMessages_en.properties or ValidatorMessages_de.properties. These properties files must be in the Classpath. Thus if you need them in an EJB module, they are placed in the root directory of the EAR.
> According to the language the right file is picked up, and the right hand side has the localized message belonging to the key on the left hand side. However, if no key is found or if the properties file isn't found, then the localized message is just "{key}" aka the template message.
> I'll attach a testcase to reproduce this issue that ValidatorMessage_xx.properties isn't found in the Classpath.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 15:25:24 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 11 Jul 2011 15:25:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1208) poor error message
 with type in logging
In-Reply-To: <512096716.37430.1309959143765.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1936768427.46445.1310412324091.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd reassigned AS7-1208:
--------------------------------

    Assignee: James Perkins  (was: David Lloyd)


> poor error message with type in logging
> ---------------------------------------
>
>                 Key: AS7-1208
>                 URL: https://issues.jboss.org/browse/AS7-1208
>             Project: Application Server 7
>          Issue Type: Quality Risk
>            Reporter: Bill Burke
>            Assignee: James Perkins
>            Priority: Minor
>
> I had a typo in logging config for standalone.xml  "TRACEy" instead of "TRACE"
> I got the obscure message of:
> 09:26:08,720 WARN  [org.jboss.as.controller] Operation ("add") failed - address: ([
>     ("subsystem" => "logging"),
>     ("periodic-rotating-file-handler" => "FILE")
> ])

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 15:32:23 2011
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Mon, 11 Jul 2011 15:32:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3126) NPE when
 retracting an object with a collection field which has been accumulated on
Message-ID: <1993932101.46455.1310412743821.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

NPE when retracting an object with a collection field which has been accumulated on
-----------------------------------------------------------------------------------

                 Key: JBRULES-3126
                 URL: https://issues.jboss.org/browse/JBRULES-3126
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Davide Sottara
            Assignee: Mark Proctor
            Priority: Critical


the engine throws a NPE in 

ReteooWorkingMemory.execute

as the "accctx" variable there is null

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 15:52:23 2011
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Mon, 11 Jul 2011 15:52:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3127) PackageBuilder
 should support an ordered iteration of added/merged packages
Message-ID: <296887291.46476.1310413943697.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

PackageBuilder should support an ordered iteration of added/merged packages 
----------------------------------------------------------------------------

                 Key: JBRULES-3127
                 URL: https://issues.jboss.org/browse/JBRULES-3127
             Project: Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-compiler
            Reporter: Davide Sottara
            Assignee: Mark Proctor
            Priority: Minor


The getPackages() method returns an array of packages which is based on the internal map's iteration order. 
Instead, the order should depend on the package addition/merge sequence.
E.g. if a KnowledgeBuilder adds the following resources:
r1 -> package p1
r2 -> package p2
r3 -> package p2
r4 -> package p3
r5 -> package p1
the sequence in the array should be p1, p3, p2

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 15:55:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 15:55:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCLUSTER-23) Consolidate
 clustering configuration frontend for state replication
Message-ID: <836391788.46482.1310414123740.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry resolved JBCLUSTER-23.
---------------------------------------

    Resolution: Out of Date


> Consolidate clustering configuration frontend for state replication
> -------------------------------------------------------------------
>
>                 Key: JBCLUSTER-23
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-23
>             Project: JBoss Clustering
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: Legacy
>
>   Original Estimate: 8 weeks
>  Remaining Estimate: 8 weeks
>
> Currently we have cluster-service.xml, tc5-cluster-serviec.xml, and other tree-cache.xml to run on tops of JGroups for various replication and clustering purpose. In ejb3, we will run into this problem of SFSB and entity bean using JBossCache.
> There comes a need to consolidate all these configuration so to a end user it is consistent.
> Solution may be to put in another integration layer to hide JBossCache configuration somewhat.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 15:57:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 15:57:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCLUSTER-26) Clustered
 deployments should be atomic
Message-ID: <858962913.46491.1310414243934.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry resolved JBCLUSTER-26.
---------------------------------------

    Resolution: Out of Date


> Clustered deployments should be atomic
> --------------------------------------
>
>                 Key: JBCLUSTER-26
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-26
>             Project: JBoss Clustering
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: Legacy
>
>   Original Estimate: 8 weeks
>  Remaining Estimate: 8 weeks
>
> Our current farm deployment is not automic, meaning that one cluster node failed, it won't rollback the rest within the cluster.
> One soultion is make the deployer XA resource so they can participate in sort of 2 phase commit.
> This can potentially be applied to MBean clustering as well.
> In addition, farming service has couple bugs outstanding. It needs an overhaul as well.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 15:57:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 15:57:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCLUSTER-10) Unified client
 side failover/load-balancing on top of Remoting
Message-ID: <937544599.46495.1310414244019.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry resolved JBCLUSTER-10.
---------------------------------------

    Resolution: Out of Date


> Unified client side failover/load-balancing on top of Remoting
> --------------------------------------------------------------
>
>                 Key: JBCLUSTER-10
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-10
>             Project: JBoss Clustering
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>            Assignee: Brian Stansberry
>             Fix For: Backlog
>
>   Original Estimate: 4 weeks
>  Remaining Estimate: 4 weeks
>
> Bill has a version that does this using the Remoting transport framework implemented in ejb3. Need further documentation and testing.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 15:57:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 15:57:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-12) Clustering
 statistics and monitoring
Message-ID: <2108959623.46499.1310414244170.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned JBCLUSTER-12:
-----------------------------------------

    Assignee:     (was: Brian Stansberry)


> Clustering statistics and monitoring
> ------------------------------------
>
>                 Key: JBCLUSTER-12
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-12
>             Project: JBoss Clustering
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>             Fix For: Legacy
>
>
> Need to implement cluster-related management attributes for tuning and monitoring. Will also need JBossCache and JGroups ones.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 15:57:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 15:57:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-17) http session
 replication benchmark and performance tuning
Message-ID: <1222199572.46503.1310414244339.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned JBCLUSTER-17:
-----------------------------------------

    Assignee:     (was: Brian Stansberry)


> http session replication benchmark and performance tuning
> ---------------------------------------------------------
>
>                 Key: JBCLUSTER-17
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-17
>             Project: JBoss Clustering
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Tier
>            Reporter: Ben Wang
>             Fix For: Legacy
>
>
> Need to benchmark http session replication using different configurations, e.g., sync mode, granularity, etc.
> Also requires JBossCache to do the same first.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 15:57:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 15:57:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-69) Create an
 analysis comparing HttpSession replication in JBoss to BEA's implementation
Message-ID: <1130580272.46505.1310414244441.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned JBCLUSTER-69:
-----------------------------------------

    Assignee:     (was: Brian Stansberry)


> Create an analysis comparing HttpSession replication in JBoss to BEA's implementation
> -------------------------------------------------------------------------------------
>
>                 Key: JBCLUSTER-69
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-69
>             Project: JBoss Clustering
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>             Fix For: Backlog
>
>
> We need to compare the features/capabilities of our session replication approach to BEA's.  The results of the analysis should be a driver for the session replication roadmap.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 15:59:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 15:59:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-78) Handling of merge
Message-ID: <821094097.46510.1310414363859.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned JBCLUSTER-78:
-----------------------------------------

    Assignee:     (was: Brian Stansberry)


> Handling of merge
> -----------------
>
>                 Key: JBCLUSTER-78
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-78
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>             Fix For: Legacy
>
>
> All building blocks which involve state do *not* implement handling of merging. E.g. DRM.mergeMembers() should invoke a callback so that each subscribed listener can handle the merge.
> This needs to be done for the existing building blocks for backward compatibility, the new mechanism used is JBossCache (see link) which will handle state merging

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 15:59:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 15:59:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCLUSTER-84) Clustering
 monitor and management under JBoss ON
Message-ID: <1374889039.46515.1310414364074.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry resolved JBCLUSTER-84.
---------------------------------------

    Resolution: Out of Date


> Clustering monitor and management under JBoss ON
> ------------------------------------------------
>
>                 Key: JBCLUSTER-84
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-84
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>            Assignee: Brian Stansberry
>             Fix For: Legacy
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 15:59:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 15:59:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-97) Integrated
 Replication for EJB3 and HttpSession
Message-ID: <2076879037.46522.1310414364307.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned JBCLUSTER-97:
-----------------------------------------

    Assignee:     (was: Brian Stansberry)


> Integrated Replication for EJB3 and HttpSession
> -----------------------------------------------
>
>                 Key: JBCLUSTER-97
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-97
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>             Fix For: Legacy
>
>
> We need to have the ability to replicate any EJB3 and http session state changes associated with a request at the same time. Otherwise, we just double the replication-related latency of the request. This is critical in the case of SEAM.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 15:59:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 15:59:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-88) Cluster
	configuration wizard
Message-ID: <1897844165.46520.1310414364211.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned JBCLUSTER-88:
-----------------------------------------

    Assignee:     (was: Brian Stansberry)


> Cluster configuration wizard
> ----------------------------
>
>                 Key: JBCLUSTER-88
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-88
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>             Fix For: Backlog
>
>
> Maybe in collaboration with JBoss Network (or maybe they are working on it).
> - Tool to configure clustering, generates e.g. cluster-service.xml file
> - First pick what needs to be clustered, e.g. base clustering (HA-JNDI etc), HTTP session replication, clustered EJB3 etc
> - Then, for each cluster, configure:
>    - what transport (default)
>    - what bind address (tool should probe for NIC and display them in a list)
>    - for TCP: list of nodes
>    - If TCP: no FRAG, no UNICAST
>    - If UDP: what mcast address, TTL, port
> - Wizard should run sanity tests after config, e.g. are clusters cleanly separated ?
> - Wizard should provide defaults, so pressing Enter on every decision leads to the default clustering config
> - Wizard should also be able to parse existing config, and reconfig it

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 15:59:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 15:59:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-141) Create a
 generic HA Singleton API
In-Reply-To: <11571445.1155964239671.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1020989820.46526.1310414364491.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned JBCLUSTER-141:
------------------------------------------

    Assignee:     (was: Brian Stansberry)


> Create a generic HA Singleton API
> ---------------------------------
>
>                 Key: JBCLUSTER-141
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-141
>             Project: JBoss Clustering
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>             Fix For: Legacy
>
>
> Also want to extract the HASingletonElectionPolicy code from the AS codebase.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 16:01:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 16:01:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-140) Examine need
 for a distributed service registry outside the AS
In-Reply-To: <9312232.1155964239551.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1677657669.46530.1310414484088.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned JBCLUSTER-140:
------------------------------------------

    Assignee:     (was: Brian Stansberry)


> Examine need for a distributed service registry outside the AS
> --------------------------------------------------------------
>
>                 Key: JBCLUSTER-140
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-140
>             Project: JBoss Clustering
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>             Fix For: Backlog
>
>
> Is something like DRM needed outside the AS?  If it is, do we want to use the JBoss Cache based version (creates JBC dependency.)
> DRM is used in two ways:
> 1) To maintain a distributed registry of remote invocation targets.
> 2) To maintain a distributed registry of services, which is done by having the service register a meaningless token under its key rather than a target.  This is used by HASingleton.
> Need to examine whether this kind of thing is needed by Messaging, or whether simple listening for view changes is sufficient.  Listening for view changes could be sufficient if each group member knew how to create a Remoting InvokerLocator for the other members based on the JGroups Address.  But, this presupposes use of consistent ports across the cluster, and that the IP address used by JGroups is the one that Messaging traffic should use.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 16:01:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 16:01:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCLUSTER-144) Consider other
 clustering code that can be removed from the AS
In-Reply-To: <9417496.1155964599660.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1435417437.46536.1310414484223.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry resolved JBCLUSTER-144.
----------------------------------------

    Resolution: Out of Date


> Consider other clustering code that can be removed from the AS
> --------------------------------------------------------------
>
>                 Key: JBCLUSTER-144
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-144
>             Project: JBoss Clustering
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: Legacy
>
>
> Things like the http session replication code that we've considered integrating into Tomcat.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 16:01:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 16:01:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-153) EJB timer
 clustering and failover support
In-Reply-To: <28686742.1163405681641.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1978005166.46547.1310414484906.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned JBCLUSTER-153:
------------------------------------------

    Assignee:     (was: Brian Stansberry)


> EJB timer clustering and failover support
> -----------------------------------------
>
>                 Key: JBCLUSTER-153
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-153
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Galder Zamarre?o
>             Fix For: Legacy
>
>
> Support for clustered EJB timer service providing failover

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul 11 16:01:25 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 16:01:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCLUSTER-184) Explore use of
 ClusteredCacheLoader to avoid state transfer
In-Reply-To: <686917.1180620788421.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1208669716.46552.1310414485510.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry resolved JBCLUSTER-184.
----------------------------------------

    Resolution: Out of Date


> Explore use of ClusteredCacheLoader to avoid state transfer
> -----------------------------------------------------------
>
>                 Key: JBCLUSTER-184
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-184
>             Project: JBoss Clustering
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: Backlog
>
>
> With CCL a cache miss results in a get call around the cluster.  Can eliminate the need for in-memory state transfer.
> Won't work with buddy replication, but could be very interesting with total replication.
> Need to think through issues with things like passivation.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 16:03:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 16:03:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-188) Possible
 further extraction of clustering code from AS codebase
In-Reply-To: <14793238.1200780081146.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2138927216.46556.1310414603866.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned JBCLUSTER-188:
------------------------------------------

    Assignee:     (was: Brian Stansberry)


> Possible further extraction of clustering code from AS codebase
> ---------------------------------------------------------------
>
>                 Key: JBCLUSTER-188
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-188
>             Project: JBoss Clustering
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>             Fix For: Legacy
>
>
> Container task for evaluating further extractions.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 16:03:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 16:03:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-204)
 Replication-based clustered Quartz job store
In-Reply-To: <8660474.1215528868486.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1935183065.46559.1310414604042.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned JBCLUSTER-204:
------------------------------------------

    Assignee:     (was: Brian Stansberry)


> Replication-based clustered Quartz job store
> --------------------------------------------
>
>                 Key: JBCLUSTER-204
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-204
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>             Fix For: Backlog
>
>
> A Quartz job store impl that uses JBoss Cache or PojoCache to coordinate around the cluster instead of the db.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 16:03:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 16:03:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-226) Make
 FamilyClusterInfoImpl internal members volatile
In-Reply-To: <16633384.1236350183270.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <589769035.46562.1310414604179.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned JBCLUSTER-226:
------------------------------------------

    Assignee:     (was: Brian Stansberry)


> Make FamilyClusterInfoImpl internal members volatile
> ----------------------------------------------------
>
>                 Key: JBCLUSTER-226
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-226
>             Project: JBoss Clustering
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: HA-Client
>    Affects Versions: HA-Client 1.1.1.GA
>            Reporter: Brian Stansberry
>             Fix For: HA-Client 2.0.0.BETA1
>
>
> At a minimum the "cursor" and "arbitraryObject" fields should be volatile.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 16:03:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 16:03:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-240) Gravitated
 sessions still exposed to background cleanup
In-Reply-To: <1068283199.1250618966649.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <396121255.46568.1310414604559.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned JBCLUSTER-240:
------------------------------------------

    Assignee:     (was: Brian Stansberry)


> Gravitated sessions still exposed to background cleanup
> -------------------------------------------------------
>
>                 Key: JBCLUSTER-240
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-240
>             Project: JBoss Clustering
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: HA-Server-Cache-JBC
>    Affects Versions: HA-Server-Cache-JBC 2.0.1.GA 
>            Reporter: Brian Stansberry
>
> Follow up to JBCLUSTER-238. Still seeing an issue:
> [JBoss] 19:08:26,233 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (OOB-58,10.34.32.156:38607) Executing command: GravitateDataCommand{fqn=/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, searchSubtrees=true} [sender=10.34.32.154:46273]
> [JBoss] 19:08:26,234 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (OOB-58,10.34.32.156:38607) Command : GravitateDataCommand{fqn=/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, searchSubtrees=true} executed, result is: GravitateResult dataFound=true nodeData=[NodeData {fqn: /JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, attrs={0=3, 1=1250615302074, 2=org.jboss.web.tomcat.service.session.distributedcache.spi.DistributableSessionMetadata at 30176a8f, 3=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw=nullserialized=true}}}] fqn=/_BUDDY_BACKUP_/10.34.32.153_2585/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__
> [JBoss] 19:08:26,571 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (Incoming-15,10.34.32.156:38607) Executing command: DataGravitationCleanupCommand{fqn=/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, backup=/_BUDDY_BACKUP_/10.34.32.153_2585/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__} [sender=10.34.32.154:46273]
> [JBoss] 19:08:26,572 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (Incoming-15,10.34.32.156:38607) Command : DataGravitationCleanupCommand{fqn=/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, backup=/_BUDDY_BACKUP_/10.34.32.153_2585/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__} executed, result is: null
> [JBoss] 19:11:36,727 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (Incoming-7,10.34.32.156:38607) Executing command: DataGravitationCleanupCommand{fqn=/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, backup=/_BUDDY_BACKUP_/10.34.32.154_46273:DEAD/1/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__} [sender=10.34.32.155:60743]
> [JBoss] 19:11:36,728 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (Incoming-7,10.34.32.156:38607) Command : DataGravitationCleanupCommand{fqn=/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, backup=/_BUDDY_BACKUP_/10.34.32.154_46273:DEAD/1/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__} executed, result is: null
> [JBoss] 19:14:24,493 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) dests=null, command=GravitateDataCommand{fqn=/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, searchSubtrees=true}, mode=2, timeout=17500
> [JBoss] 19:14:24,496 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) responses: [sender=10.34.32.153:47135, retval=GravitateResult dataFound=true nodeData=[NodeData {fqn: /JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, attrs={0=92, 1=1250615662411, 2=org.jboss.web.tomcat.service.session.distributedcache.spi.DistributableSessionMetadata at 2e075959, 3=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw=nullserialized=true}}}] fqn=/_BUDDY_BACKUP_/10.34.32.155_60743/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, received=true, suspected=false]
> [JBoss] [sender=10.34.32.155:60743, retval=GravitateResult dataFound=true nodeData=[NodeData {fqn: /JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, attrs={0=92, 1=1250615662411, 2=org.jboss.web.tomcat.service.session.distributedcache.spi.DistributableSessionMetadata at 647af9aa, 3=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw=nullserialized=true}}}] fqn=/_BUDDY_BACKUP_/10.34.32.155_60743/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, received=true, suspected=false]
> [JBoss] 19:14:24,497 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) dests=[10.34.32.155:60743], command=ReplicateCommand{cmds=PrepareCommand{globalTransaction=GlobalTransaction:&lt;10.34.32.156:38607>:203, modifications=[PutDataMapCommand{fqn=/_BUDDY_BACKUP_/10.34.32.156_38607/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, dataVersion=null, data={0=92, 1=1250615662411, 2=org.jboss.web.tomcat.service.session.distributedcache.spi.DistributableSessionMetadata at 2e075959, 3=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw={payLoad=org.jboss.test.cluster.servlet.SessionPayload at 55a9181d}serialized=false}}, globalTransaction=null, erase=false}], localAddress=10.34.32.156:38607, onePhaseCommit=false}}, mode=2, timeout=17500
> [JBoss] 19:14:24,499 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) dests=null, command=DataGravitationCleanupCommand{fqn=/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__, backup=/_BUDDY_BACKUP_/10.34.32.155_60743/JSESSION/st_localhost/S8EqfyNmGtWeAeTjRnG5fA__}, mode=6, timeout=-1
> The background thread should not be interested in this session.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 16:03:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 16:03:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-275) Handle
 MergeViews in AbstractClusterLockSupport variants
In-Reply-To: <1402585096.1253216989268.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1670410746.46570.1310414604695.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned JBCLUSTER-275:
------------------------------------------

    Assignee:     (was: Brian Stansberry)


> Handle MergeViews in AbstractClusterLockSupport variants
> --------------------------------------------------------
>
>                 Key: JBCLUSTER-275
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-275
>             Project: JBoss Clustering
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: HA-Server-API
>            Reporter: Brian Stansberry
>
> org.jboss.ha.framework.server.lock.AbstractClusterLockSupport and/or its subclasses need to deal with cluster merges, i.e. AS instances in groups {A, B} and {C, D} discover each other and form a single group {A, B, C, D}. Following a merge, it's possible a node in each of the merged subgroups thinks it has the cluster wide lock.
> A simple approach that *may* work in all cases is to handle a merge by having each node abandon the cluster-wide lock, forcing the next attempt by a local caller to re-acquire the lock. Need to think through though whether that is the correct semantic in all cases.
> AbstractClusterLockSupport needs to implement HAExtendedMembershipListener instead of just HAMembershipListener; this will allow it to know whether a view change was due to a merge.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 16:05:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 16:05:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-274) Lock ownership
 change notifications
In-Reply-To: <1877922746.2012.1274732274961.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <654597180.46589.1310414724339.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned JBCLUSTER-274:
------------------------------------------

    Assignee:     (was: Brian Stansberry)


> Lock ownership change notifications
> -----------------------------------
>
>                 Key: JBCLUSTER-274
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-274
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: HA-Server-API
>            Reporter: Brian Stansberry
>
> Add an ability to register for a notification when ownership of a particular lock changes.
> For example, with HttpSession clustering backed by JBC, we currently get callbacks when the cache changes, allowing us to know a local copy of a session is out of date with respect to the distributed cache. That won't work with DIST as the notification is not reliable. But another node taking ownership of the session will be noticed by the local lock manager, which could invoke a notification on the session manager.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 16:05:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 16:05:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-276) More
 sophisticated state transfer handling
In-Reply-To: <1533918218.875.1275361431710.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <319773994.46592.1310414724458.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned JBCLUSTER-276:
------------------------------------------

    Assignee:     (was: Brian Stansberry)


> More sophisticated state transfer handling
> ------------------------------------------
>
>                 Key: JBCLUSTER-276
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-276
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: HA-Server-API
>            Reporter: Brian Stansberry
>             Fix For: HA-Server-API 2.0.0.Beta1
>
>
> StateTransferProvider capable of returning a stream. GroupStateTransferService to expose getStateAsStream().

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 16:05:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 16:05:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-281) Improve Channel
 management so HAPartition can integrate more easily
In-Reply-To: <435333256.341.1275583617055.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <72671760.46595.1310414724570.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned JBCLUSTER-281:
------------------------------------------

    Assignee:     (was: Brian Stansberry)


> Improve Channel management so HAPartition can integrate more easily
> -------------------------------------------------------------------
>
>                 Key: JBCLUSTER-281
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-281
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: HA-Server-Cache-JBC
>            Reporter: Brian Stansberry
>             Fix For: HA-Server-Cache-JBC 2.4.0.Final 
>
>
> The HAPartition in ha-server-core is based around the JGroups MuxRpcDispatcher and thus shares a ref to Channel with the cache instance used for DistributedState. Improve the integration to make it easier for HAPartition and the cache to coordinate getting a ref to and starting the channel.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 16:05:25 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 16:05:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-290) Not able to
 create a distributed cache
In-Reply-To: <328194987.14694.1289273101373.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <538614796.46614.1310414725231.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned JBCLUSTER-290:
------------------------------------------

    Assignee:     (was: Brian Stansberry)


> Not able to create a distributed cache
> --------------------------------------
>
>                 Key: JBCLUSTER-290
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-290
>             Project: JBoss Clustering
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: HA-Server-Cache-ISPN
>    Affects Versions: HA-Server-Cache-ISPN 1.0.0.Final 
>            Reporter: Rick Dong
>
> if changing the cluster mode to 'distribution', the properties would not be carried over from the default configuration and CHANNEL_LOOKUP would be missing which resulting in the following exception:
> Caused by: java.lang.Exception: unable to load class for protocol UFC (either as an absolute - UFC - or relative - org.jgroups.protocols.UFC - package name)!
> 	at org.jgroups.stack.Configurator$ProtocolConfiguration.createLayer(Configurator.java:1241)
> 	at org.jgroups.stack.Configurator$ProtocolConfiguration.access$000(Configurator.java:1132)
> 	at org.jgroups.stack.Configurator.createProtocols(Configurator.java:363)
> 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:89)
> 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:55)
> 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:453)
> 	at org.jgroups.JChannel.init(JChannel.java:1699)
> 	... 30 more
> this seems to be caused by the fix to https://jira.jboss.org/browse/ISPN-744
> below is the configuration for infinispan:
> <?xml version="1.0" encoding="UTF-8"?>
> <infinispan
>       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>       xsi:schemaLocation="urn:infinispan:config:4.2 http://www.infinispan.org/schemas/infinispan-config-4.2.xsd"
>       xmlns="urn:infinispan:config:4.2">
>    <!-- *************************** -->
>    <!-- System-wide global settings -->
>    <!-- *************************** -->
>    <global>
>       <!-- Note that if these are left blank, defaults are used.  See the user guide for what these defaults are -->
>       <asyncListenerExecutor factory="org.infinispan.executors.DefaultExecutorFactory">
>          <properties>
>          	<property name="maxThreads" value="5"/>
>          	<property name="threadNamePrefix" value="AsyncListenerThread"/>
>          </properties>
>       </asyncListenerExecutor>
>       <asyncTransportExecutor factory="org.infinispan.executors.DefaultExecutorFactory">
>          <properties>
>          	<property name="maxThreads" value="25"/>
>          	<property name="threadNamePrefix" value="AsyncSerializationThread"/>
>          </properties>
>       </asyncTransportExecutor>
>       <evictionScheduledExecutor factory="org.infinispan.executors.DefaultScheduledExecutorFactory">
>          <properties>
>          	<property name="threadNamePrefix" value="EvictionThread"/>
>          </properties>
>       </evictionScheduledExecutor>
>       <replicationQueueScheduledExecutor factory="org.infinispan.executors.DefaultScheduledExecutorFactory">
>          <properties>
>          	<property name="threadNamePrefix" value="ReplicationQueueThread"/>
>          </properties>
>       </replicationQueueScheduledExecutor>
>       <globalJmxStatistics enabled="true" jmxDomain="infinispan"/>
>       <!--
>          If the transport is omitted, there is no way to create distributed or clustered caches.
>          There is no added cost to defining a transport but not creating a cache that uses one, since the transport
>          is created and initialized lazily.
>       -->
>       <transport clusterName="infinispan-cluster" machineId="m1" rackId="r1" siteId="s1" distributedSyncTimeout="50000" nodeName="Jalapeno"/>
>          <!-- Note that the JGroups transport uses sensible defaults if no configuration property is defined. -->
>          <!-- See the JGroupsTransport javadocs for more flags -->
>       <!-- Again, sensible defaults are used here if this is omitted.  -->
>       <serialization marshallerClass="org.infinispan.marshall.VersionAwareMarshaller" version="1.0"/>
>       <!--
>          Used to register JVM shutdown hooks.
>          hookBehavior: DEFAULT, REGISTER, DONT_REGISTER
>       -->
>       <shutdown hookBehavior="DEFAULT"/>
>    </global>
>    <!-- *************************** -->
>    <!-- Default "template" settings -->
>    <!-- *************************** -->
>    <!-- this is used as a "template" configuration for all caches in the system. -->
>    <default>
>       <!--
>          isolation levels supported: READ_COMMITTED and REPEATABLE_READ
>       -->
>       <locking
>             isolationLevel="REPEATABLE_READ"
>             lockAcquisitionTimeout="20000"
>             writeSkewCheck="false"
>             concurrencyLevel="500"
>             useLockStriping="true"
>             />
>       <!--                                 //http://community.jboss.org/wiki/LockingandConcurrency#Locking_a_single_remote_node
>       Used to register a transaction manager and participate in ongoing transactions.
>       -->
>       <transaction
>             transactionManagerLookupClass="org.infinispan.transaction.lookup.GenericTransactionManagerLookup"
>             syncRollbackPhase="false"
>             syncCommitPhase="false"
>             useEagerLocking="true" eagerLockSingleNode="true"/>
>       <!--
>       Used to register JMX statistics in any available MBean server
>       -->
>       <jmxStatistics enabled="false"/>
>       <lazyDeserialization enabled="false"/>
>       <!--
>          Used to enable invocation batching and allow the use of Cache.startBatch()/endBatch() methods.
>       -->
>       <invocationBatching enabled="true"/>
>       <!--
>          This element specifies that the cache is clustered.
>          modes supported: distribution (d), replication (r) or invalidation (i).
>       -->
>       <clustering mode="d">
>       </clustering>
>    </default>
>    
> </infinispan>
> and the jgroup stack config
> <?xml version="1.0" encoding="UTF-8"?>
> <!--
>   Sample file that defines a number of stacks, used by the multiplexer
>   Author: Bela Ban
>   Version: $Id: jgroups-stacks.xml 14257 2007-12-23 14:46:37Z bstansberry at jboss.com $
> -->
> <protocol_stacks>
>     <stack name="udp"
>            description="Default: IP multicast based stack, with flow control and message bundling">
>         <config>
>             <UDP
>                  mcast_addr="${jgroups.udp.mcast_addr:228.10.10.10}"
>                  mcast_port="${jgroups.udp.mcast_port:45588}"
>                  tos="8"
>                  ucast_recv_buf_size="20000000"
>                  ucast_send_buf_size="640000"
>                  mcast_recv_buf_size="25000000"
>                  mcast_send_buf_size="640000"
>                  loopback="true"
>                  discard_incompatible_packets="true"
>                  max_bundle_size="64000"
>                  max_bundle_timeout="30"
>                  use_incoming_packet_handler="true"
>                  ip_ttl="${jgroups.udp.ip_ttl:2}"
>                  enable_bundling="${jgroup.udp.enable_bundling:true}"
>                  
>                  use_concurrent_stack="true"
> 		         thread_pool.enabled="true"
> 		         thread_pool.min_threads="1"
> 		         thread_pool.max_threads="25"
> 		         thread_pool.keep_alive_time="5000"
> 		         thread_pool.queue_enabled="false"
> 		         thread_pool.queue_max_size="100"
> 		         thread_pool.rejection_policy="Run"
> 		
> 		         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="Run"/>		         
>             <PING timeout="${jgroups.ping.timeout:2000}"
>                     num_initial_members="${jgroups.ping.num_initial_members:3}"/>
>             <MERGE2 max_interval="100000"
>                       min_interval="20000"/>
>             <FD_SOCK/>
>             <FD timeout="10000" max_tries="5" shun="true"/>
>             <VERIFY_SUSPECT timeout="1500"  />
>             <pbcast.NAKACK
>                            use_mcast_xmit="false" gc_lag="0"
>                            retransmit_timeout="300,600,1200,2400,4800"
>                            discard_delivered_msgs="false"/>
>             <UNICAST timeout="300,600,1200,2400,3600"/>
>             <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
>                            max_bytes="400000"/>
>             <pbcast.GMS print_local_addr="true" 
>                         join_timeout="3000"  
>                         shun="false"
>                         view_bundling="true"
>                         view_ack_collection_timeout="5000"/>
>             <FC max_credits="2000000"
>                 min_threshold="0.10"/>
>             <FRAG2 frag_size="60000"  />
> 			<pbcast.STREAMING_STATE_TRANSFER/>
> 	        <!-- <pbcast.STATE_TRANSFER/> -->
> 	        <pbcast.FLUSH timeout="0"/>        
> 	    </config>
>     </stack>
> </protocol_stacks>

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 16:05:25 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 16:05:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-119) Effect of
 different JGroups transports
Message-ID: <1606078805.46618.1310414725496.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned JBCLUSTER-119:
------------------------------------------

    Assignee:     (was: Brian Stansberry)


> Effect of different JGroups transports
> --------------------------------------
>
>                 Key: JBCLUSTER-119
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-119
>             Project: JBoss Clustering
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Web Tier
>            Reporter: Brian Stansberry
>             Fix For: Legacy
>
>         Attachments: ResultsExtract.pdf, tc5-cluster-service.xml.nio, tc5-cluster-service.xml.tcp, tc5-cluster-service.xml.udp
>
>
> Need to see in which cluster topologies UDP, TCP and TCP_NIO perform best.  Particularly, how big of a cluster before UDP pays off.  Need to factor buddy replication into this.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 16:07:30 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 16:07:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-203) Genericize
	FamilyClusterInfo
In-Reply-To: <25893711.1213981417776.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <255399108.46638.1310414850825.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned JBCLUSTER-203:
------------------------------------------

    Assignee:     (was: Brian Stansberry)


> Genericize FamilyClusterInfo
> ----------------------------
>
>                 Key: JBCLUSTER-203
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-203
>             Project: JBoss Clustering
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: HA-Client
>            Reporter: Brian Stansberry
>            Priority: Minor
>             Fix For: HA-Client 2.0.0.BETA1
>
>
> Mostly using List<Object> for the targets

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 16:07:31 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 16:07:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-229) Comparison of
 String objects using == in FamilyClusterInfoImpl.equals(Object)
In-Reply-To: <32660365.1238556382829.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <424334563.46641.1310414851011.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned JBCLUSTER-229:
------------------------------------------

    Assignee:     (was: Brian Stansberry)


> Comparison of String objects using == in FamilyClusterInfoImpl.equals(Object) 
> ------------------------------------------------------------------------------
>
>                 Key: JBCLUSTER-229
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-229
>             Project: JBoss Clustering
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>            Priority: Minor
>             Fix For: HA-Client 2.0.0.BETA1
>
>
> return fr.familyName == this.familyName;
> Minor issue as this is semi-valid since the familyName field comes via ClusteringTargetsRepository, which ensures only a single String gets passed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 16:07:31 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 16:07:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-231)
 ClusteringTargetsRepository.families isn't final but should be
In-Reply-To: <12232906.1238599642593.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <704974534.46644.1310414851186.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned JBCLUSTER-231:
------------------------------------------

    Assignee:     (was: Brian Stansberry)


> ClusteringTargetsRepository.families isn't final but should be
> --------------------------------------------------------------
>
>                 Key: JBCLUSTER-231
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-231
>             Project: JBoss Clustering
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>            Priority: Minor
>             Fix For: HA-Client 2.0.0.BETA1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 16:07:31 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 16:07:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCLUSTER-237) Improve
 ClusterChooserInterceptor exception messages
In-Reply-To: <31712902.1244580236721.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1518103232.46662.1310414851991.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned JBCLUSTER-237:
------------------------------------------

    Assignee:     (was: Brian Stansberry)


> Improve ClusterChooserInterceptor exception messages
> ----------------------------------------------------
>
>                 Key: JBCLUSTER-237
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-237
>             Project: JBoss Clustering
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: HA-Client
>            Reporter: Brian Stansberry
>            Priority: Minor
>             Fix For: HA-Client 2.0.0.BETA1
>
>
> Stuff like the following needs improvement:
> target = (InvokerLocator) lb.chooseTarget(family.get());
>          if (target == null)
>          {
>             if (lastException != null)
>             {
>                throw new RuntimeException("cluster invocation failed, last exception was: ", lastException);
>             }
>             else
>             {
>                throw new RuntimeException("cluster invocation failed");
>             }
>          }
>          failoverCounter++;
>       }
>       // if we get here this means list was exhausted
>       throw new RuntimeException("Unreachable?: Service unavailable.");

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 16:09:25 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 16:09:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (AS7-1254) Set the port_range on
 JGroups stacks to 1
In-Reply-To: <59508402.1271098417733.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1258519170.46709.1310414965074.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry moved JBAS-7930 to AS7-1254:
---------------------------------------------

          Project: Application Server 7  (was: Legacy JBoss Application Server 6 )
              Key: AS7-1254  (was: JBAS-7930)
         Workflow: GIT Pull Request workflow   (was: jira)
      Component/s: Clustering
                       (was: Clustering)
         Security:     (was: Public)
    Fix Version/s:     (was: No Release)


> Set the port_range on JGroups stacks to 1
> -----------------------------------------
>
>                 Key: AS7-1254
>                 URL: https://issues.jboss.org/browse/AS7-1254
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Clustering
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> Lock down the ports.
> Do this for M4 as it may lead to testsuite troubles on slaves until we identify ports where there aren't conflicts.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 16:11:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 16:11:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1254) Set the port_range on
 JGroups stacks to 1
In-Reply-To: <59508402.1271098417733.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <825317534.46727.1310415084243.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-1254:
----------------------------------

         Assignee:     (was: Brian Stansberry)
    Fix Version/s: 7.1.0.Beta2
      Description: Lock down the ports.  (was: Lock down the ports.

Do this for M4 as it may lead to testsuite troubles on slaves until we identify ports where there aren't conflicts.)


> Set the port_range on JGroups stacks to 1
> -----------------------------------------
>
>                 Key: AS7-1254
>                 URL: https://issues.jboss.org/browse/AS7-1254
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Clustering
>            Reporter: Brian Stansberry
>             Fix For: 7.1.0.Beta2
>
>
> Lock down the ports.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 16:11:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 16:11:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7944) Move
 GlobalDiscoveryDisableTestCase to defaultcfg package
In-Reply-To: <736845794.1271352926101.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1138934900.46730.1310415084372.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry resolved JBAS-7944.
------------------------------------

    Resolution: Won't Fix


> Move GlobalDiscoveryDisableTestCase to defaultcfg package
> ---------------------------------------------------------
>
>                 Key: JBAS-7944
>                 URL: https://issues.jboss.org/browse/JBAS-7944
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Test Suite
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: No Release
>
>
> AFAICT this test doesn't need to be run with different JGroups stacks.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 16:11:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 16:11:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (AS7-1255) Investigate making
 HASingleton failover "stopOldMaster" RPC synchronous
In-Reply-To: <433116467.1273178285723.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <796786358.46732.1310415084464.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry moved JBAS-7999 to AS7-1255:
---------------------------------------------

        Project: Application Server 7  (was: Legacy JBoss Application Server 6 )
            Key: AS7-1255  (was: JBAS-7999)
     Issue Type: Feature Request  (was: Task)
       Workflow: GIT Pull Request workflow   (was: jira)
    Component/s: Clustering
                     (was: Clustering)
       Security:     (was: Public)


> Investigate making HASingleton failover "stopOldMaster" RPC synchronous
> -----------------------------------------------------------------------
>
>                 Key: AS7-1255
>                 URL: https://issues.jboss.org/browse/AS7-1255
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> When a node becomes master, it tells any previous master to stop. That call is async, probably because long ago this was done on a JGroups up thread and making a sync call from that up thread would hang. This is no longer done on an up thread, so investigate adding a config option to allow is call to go synchronous, thus ensuring the old master is fully stopped before new one starts.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 16:13:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 16:13:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1255) Investigate making
 HASingleton failover "stopOldMaster" RPC synchronous
In-Reply-To: <433116467.1273178285723.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1202736923.46751.1310415203810.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned AS7-1255:
-------------------------------------

    Assignee:     (was: Brian Stansberry)


> Investigate making HASingleton failover "stopOldMaster" RPC synchronous
> -----------------------------------------------------------------------
>
>                 Key: AS7-1255
>                 URL: https://issues.jboss.org/browse/AS7-1255
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Brian Stansberry
>
> When a node becomes master, it tells any previous master to stop. That call is async, probably because long ago this was done on a JGroups up thread and making a sync call from that up thread would hang. This is no longer done on an up thread, so investigate adding a config option to allow is call to go synchronous, thus ensuring the old master is fully stopped before new one starts.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 16:29:23 2011
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 11 Jul 2011 16:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-9164) Upgrade to latest
 available version of RESTEasy
In-Reply-To: <287187962.3539.1301318737980.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <12537217.46814.1310416163793.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Shelly McGowan commented on JBAS-9164:
--------------------------------------

RESTEasy 2.2.1.GA is available:
https://repository.jboss.org/nexus/content/groups/public/org/jboss/resteasy/resteasy-jaxrs/2.2.1.GA/

> Upgrade to latest available version of RESTEasy
> -----------------------------------------------
>
>                 Key: JBAS-9164
>                 URL: https://issues.jboss.org/browse/JBAS-9164
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>            Reporter: Jozef Hartinger
>            Assignee: Daniel Bevenius
>             Fix For: 6.1.0
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 18:39:23 2011
From: jira-events at lists.jboss.org (Jim Tyrrell (JIRA))
Date: Mon, 11 Jul 2011 18:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1236) copied lib
 directory in the deployments directory results in deployment
In-Reply-To: <1720824389.42997.1310155524058.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <168650951.46935.1310423963777.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jim Tyrrell commented on AS7-1236:
----------------------------------

Okay I guess on the .failed markers, but I have to ask a question, so if we are deploying just things likes .war, .ear, .sar, and a host of other well known extensions, why would this even happen.  In the past I thought there was a "deployable" list of extensions JBoss AS/EAP would look at what changed requirement/need wise, or was this just some oversight?  Also curious does stuff like this end up in unit tests?  How would I look at those if they exist?

> copied lib directory in the deployments directory results in deployment
> -----------------------------------------------------------------------
>
>                 Key: AS7-1236
>                 URL: https://issues.jboss.org/browse/AS7-1236
>             Project: Application Server 7
>          Issue Type: Feature Request
>         Environment: JBoss AS 7 CR 1
>            Reporter: Jim Tyrrell
>            Assignee: Brian Stansberry
>             Fix For: 7.0.0.Final
>
>         Attachments: Sample.war
>
>
> Having an existing zipped up war file, and then unzipping it in the deployment directory, creates a lib directory that has a bunch of jar files in it.  It appears that these jar files in this lib directory are marked as .failed as they are tried to be deployed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 19:00:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 19:00:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1236) copied lib
 directory in the deployments directory results in deployment
In-Reply-To: <1720824389.42997.1310155524058.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <608331425.46944.1310425223846.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on AS7-1236:
---------------------------------------

One of the well known extensions is .jar, the standard deployment type for an ejb deployment.

Most of the unit tests around scanner behavior can be found in https://github.com/jbossas/jboss-as/blob/master/deployment-scanner/src/test/java/org/jboss/as/server/deployment/scanner/FileSystemDeploymentServiceUnitTestCase.java

> copied lib directory in the deployments directory results in deployment
> -----------------------------------------------------------------------
>
>                 Key: AS7-1236
>                 URL: https://issues.jboss.org/browse/AS7-1236
>             Project: Application Server 7
>          Issue Type: Feature Request
>         Environment: JBoss AS 7 CR 1
>            Reporter: Jim Tyrrell
>            Assignee: Brian Stansberry
>             Fix For: 7.0.0.Final
>
>         Attachments: Sample.war
>
>
> Having an existing zipped up war file, and then unzipping it in the deployment directory, creates a lib directory that has a bunch of jar files in it.  It appears that these jar files in this lib directory are marked as .failed as they are tried to be deployed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 19:06:23 2011
From: jira-events at lists.jboss.org (Jim Tyrrell (JIRA))
Date: Mon, 11 Jul 2011 19:06:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1236) copied lib
 directory in the deployments directory results in deployment
In-Reply-To: <1720824389.42997.1310155524058.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1713803018.46949.1310425583661.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jim Tyrrell commented on AS7-1236:
----------------------------------

Yeah I get that a jar file is a standard deployment, but it is usually in the context of a war/ear/etc....just found it odd that something in a directory that did not end in the well known types (war, ear, sar, etc) would be scanned, and then that it would be crawled it, and .failed file would be created in the exploded directory..just odd to me.

Are there cases where other "things" could be done to an exploded directory? 

> copied lib directory in the deployments directory results in deployment
> -----------------------------------------------------------------------
>
>                 Key: AS7-1236
>                 URL: https://issues.jboss.org/browse/AS7-1236
>             Project: Application Server 7
>          Issue Type: Feature Request
>         Environment: JBoss AS 7 CR 1
>            Reporter: Jim Tyrrell
>            Assignee: Brian Stansberry
>             Fix For: 7.0.0.Final
>
>         Attachments: Sample.war
>
>
> Having an existing zipped up war file, and then unzipping it in the deployment directory, creates a lib directory that has a bunch of jar files in it.  It appears that these jar files in this lib directory are marked as .failed as they are tried to be deployed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 19:17:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 19:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1236) copied lib
 directory in the deployments directory results in deployment
In-Reply-To: <1720824389.42997.1310155524058.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <469463741.46955.1310426243687.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on AS7-1236:
---------------------------------------

There is no requirement that an ejb deployment has to be packaged in an ear or a war. So if the scanner sees a .jar, it assumes it's an ejb deployment and tries to deploy it. This isn't new behavior; the scanner in AS 5 and 6 if it sees a directory it checks if its filename matches one of the expected extensions; if yes it tries to deploy it as an exploded deployment; if no it recurses into it looking for deployments. I believe the same is true in AS 3 and 4 as well.

The only difference in AS 7 is we write out the .failed files. 

> copied lib directory in the deployments directory results in deployment
> -----------------------------------------------------------------------
>
>                 Key: AS7-1236
>                 URL: https://issues.jboss.org/browse/AS7-1236
>             Project: Application Server 7
>          Issue Type: Feature Request
>         Environment: JBoss AS 7 CR 1
>            Reporter: Jim Tyrrell
>            Assignee: Brian Stansberry
>             Fix For: 7.0.0.Final
>
>         Attachments: Sample.war
>
>
> Having an existing zipped up war file, and then unzipping it in the deployment directory, creates a lib directory that has a bunch of jar files in it.  It appears that these jar files in this lib directory are marked as .failed as they are tried to be deployed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 19:22:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 11 Jul 2011 19:22:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1234) Hibernate does not
 read/use metadata for orm.xml defined entites
In-Reply-To: <461439061.42234.1310135790589.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1314228281.46972.1310426543932.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved AS7-1234.
---------------------------------

         Assignee: Stuart Douglas  (was: Scott Marlow)
    Fix Version/s: 7.0.0.Final
       Resolution: Rejected


You module.xml file is missing a dependency on javax.persistence.api, which means that the JVM is silently ignoring the annotations. 

> Hibernate does not read/use metadata for orm.xml defined entites
> ----------------------------------------------------------------
>
>                 Key: AS7-1234
>                 URL: https://issues.jboss.org/browse/AS7-1234
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta3, 7.0.0.CR1, 7.0.0.Final, 7.0.1.Final, 7.1.0.Alpha1
>         Environment: windows 7, sql server 2008 r2
>            Reporter: Tomaz Cerar
>            Assignee: Stuart Douglas
>             Fix For: 7.0.0.Final
>
>         Attachments: module.zip, webapp-1.0.war
>
>
> I have setup where we have "common" entities defined in global lib/module that application(war/ear) in then dependent on.
> Then I declare this entities in orm.xml of my application just by class name.
> for instance:
> {code:xml}
> <entity class="com.company.module.Article"/>
> <entity class="com.company.module.Binary"/>
> <entity class="com.company.module.Category"/>
> {code}
> Up until as7/hibernate 4 this worked with no problems, but now it dies with exception "no id defined on entity Article". If I defined id in orm.xml it then finds id field but fails to find anything that is annotated on classes. 
> It looks like metadata is not read for this classes and hibernate sees them as just plain pojo with no annotations.
> I am guessing that problem has to do something with integration with AS7 that now has jandex index for all annotations...

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 20:06:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 11 Jul 2011 20:06:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1256) <jar-file> in
 persistence.xml does not work
Message-ID: <1794857022.47048.1310429183676.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

<jar-file> in persistence.xml does not work
-------------------------------------------

                 Key: AS7-1256
                 URL: https://issues.jboss.org/browse/AS7-1256
             Project: Application Server 7
          Issue Type: Bug
          Components: JPA / Hibernate
    Affects Versions: 7.0.0.CR1, 7.0.0.Final
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas
             Fix For: 7.0.1.Final


HibernateAnnotationScanner does not correctly handle jar files other than the one contained in persistence.xml

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 20:06:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 11 Jul 2011 20:06:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1256) <jar-file> in
 persistence.xml does not work
In-Reply-To: <1794857022.47048.1310429183676.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <40355139.47052.1310429183779.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas updated AS7-1256:
--------------------------------

    Description: HibernateAnnotationScanner does not correctly handle jar files other than the one containing persistence.xml  (was: HibernateAnnotationScanner does not correctly handle jar files other than the one contained in persistence.xml)


> <jar-file> in persistence.xml does not work
> -------------------------------------------
>
>                 Key: AS7-1256
>                 URL: https://issues.jboss.org/browse/AS7-1256
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.CR1, 7.0.0.Final
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 7.0.1.Final
>
>
> HibernateAnnotationScanner does not correctly handle jar files other than the one containing persistence.xml

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 20:19:23 2011
From: jira-events at lists.jboss.org (Jim Tyrrell (JIRA))
Date: Mon, 11 Jul 2011 20:19:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1236) copied lib
 directory in the deployments directory results in deployment
In-Reply-To: <1720824389.42997.1310155524058.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1168338458.47067.1310429963679.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jim Tyrrell commented on AS7-1236:
----------------------------------

Okay I get the above, but this is a directory in this case lib, with a bunch of jar files in it, how come AS7 reaches into that directory, I guess is the question?

> copied lib directory in the deployments directory results in deployment
> -----------------------------------------------------------------------
>
>                 Key: AS7-1236
>                 URL: https://issues.jboss.org/browse/AS7-1236
>             Project: Application Server 7
>          Issue Type: Feature Request
>         Environment: JBoss AS 7 CR 1
>            Reporter: Jim Tyrrell
>            Assignee: Brian Stansberry
>             Fix For: 7.0.0.Final
>
>         Attachments: Sample.war
>
>
> Having an existing zipped up war file, and then unzipping it in the deployment directory, creates a lib directory that has a bunch of jar files in it.  It appears that these jar files in this lib directory are marked as .failed as they are tried to be deployed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 20:21:23 2011
From: jira-events at lists.jboss.org (Jim Tyrrell (JIRA))
Date: Mon, 11 Jul 2011 20:21:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1236) copied lib
 directory in the deployments directory results in deployment
In-Reply-To: <1720824389.42997.1310155524058.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2043186111.47073.1310430083682.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jim Tyrrell commented on AS7-1236:
----------------------------------

I can confirm that EAP 5.1 does "deploy" the lib folder with a collection of jar files...interesting for sure....

> copied lib directory in the deployments directory results in deployment
> -----------------------------------------------------------------------
>
>                 Key: AS7-1236
>                 URL: https://issues.jboss.org/browse/AS7-1236
>             Project: Application Server 7
>          Issue Type: Feature Request
>         Environment: JBoss AS 7 CR 1
>            Reporter: Jim Tyrrell
>            Assignee: Brian Stansberry
>             Fix For: 7.0.0.Final
>
>         Attachments: Sample.war
>
>
> Having an existing zipped up war file, and then unzipping it in the deployment directory, creates a lib directory that has a bunch of jar files in it.  It appears that these jar files in this lib directory are marked as .failed as they are tried to be deployed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 20:37:23 2011
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 11 Jul 2011 20:37:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3128) Create a JON/RHQ
 plugin for Drools
Message-ID: <686968631.47090.1310431043615.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Create a JON/RHQ plugin for Drools
----------------------------------

                 Key: JBRULES-3128
                 URL: https://issues.jboss.org/browse/JBRULES-3128
             Project: Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Edson Tirelli
            Assignee: Edson Tirelli


Create a fully functional JON/RHQ plugin for Drools based on the POC developed a few years ago. Use latest Drools and RHQ versions.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 20:39:23 2011
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 11 Jul 2011 20:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-3128) Create a JON/RHQ
 plugin for Drools
In-Reply-To: <686968631.47090.1310431043615.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2131423606.47092.1310431163619.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Edson Tirelli updated JBRULES-3128:
-----------------------------------

        Fix Version/s: 5.2.1.Final
                       5.3.0.Beta1
    Affects Version/s: 5.2.0.Final
          Component/s: drools-core


> Create a JON/RHQ plugin for Drools
> ----------------------------------
>
>                 Key: JBRULES-3128
>                 URL: https://issues.jboss.org/browse/JBRULES-3128
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.2.0.Final
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.2.1.Final, 5.3.0.Beta1
>
>
> Create a fully functional JON/RHQ plugin for Drools based on the POC developed a few years ago. Use latest Drools and RHQ versions.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 21:09:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 11 Jul 2011 21:09:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1236) copied lib
 directory in the deployments directory results in deployment
In-Reply-To: <1720824389.42997.1310155524058.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1743226388.47101.1310432963882.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on AS7-1236:
---------------------------------------

The scanner allows subdirectories under deploy/ (AS < 7) or deployments/ that aren't exploded deployments as a means to allow organization of content. For example, in AS 5 I organized all the clustering related deployments under deploy/cluster/. If a directory doesn't have a name that causes the scanner to treat it as an exploded deployment, the scanner assumes it's there for organization of content and steps into it.

> copied lib directory in the deployments directory results in deployment
> -----------------------------------------------------------------------
>
>                 Key: AS7-1236
>                 URL: https://issues.jboss.org/browse/AS7-1236
>             Project: Application Server 7
>          Issue Type: Feature Request
>         Environment: JBoss AS 7 CR 1
>            Reporter: Jim Tyrrell
>            Assignee: Brian Stansberry
>             Fix For: 7.0.0.Final
>
>         Attachments: Sample.war
>
>
> Having an existing zipped up war file, and then unzipping it in the deployment directory, creates a lib directory that has a bunch of jar files in it.  It appears that these jar files in this lib directory are marked as .failed as they are tried to be deployed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 22:16:23 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Mon, 11 Jul 2011 22:16:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMESSAGING-1885) Duplicated
 message delivery in closing a connection while a transaction is committing
In-Reply-To: <230950532.42441.1310137405043.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1150571091.47126.1310436983792.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao resolved JBMESSAGING-1885.
---------------------------------------

    Resolution: Done


> Duplicated message delivery in closing a connection while a transaction is committing
> -------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1885
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1885
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP13, 1.4.8.SP1
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP14, 1.4.8.SP2
>
>
> A message may be delivered twice when the following events happens in order:
> 1. A client receives a message in a transaction and is committing it. In the meantime the connection is closed (by, for example, user shut down the client application) in another thread.
> 2. At the server side, the connection closing will cause the message (not prepared) to be cancelled back to queue. In the meantime the committing will remove the message. Both actions are performed concurrently.
> 3. If the committing happens before the connection closing, transaction commit successfully and message won't get cancelled. But if the committing happens after connection closing, there is a chance the message is cancelled back to queue and  yet the transaction is committed successfully. So the message will be delivered twice.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 22:16:23 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Mon, 11 Jul 2011 22:16:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1885) Duplicated
 message delivery in closing a connection while a transaction is committing
In-Reply-To: <230950532.42441.1310137405043.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1405245903.47130.1310436983898.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao closed JBMESSAGING-1885.
-------------------------------------



> Duplicated message delivery in closing a connection while a transaction is committing
> -------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1885
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1885
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP13, 1.4.8.SP1
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP14, 1.4.8.SP2
>
>
> A message may be delivered twice when the following events happens in order:
> 1. A client receives a message in a transaction and is committing it. In the meantime the connection is closed (by, for example, user shut down the client application) in another thread.
> 2. At the server side, the connection closing will cause the message (not prepared) to be cancelled back to queue. In the meantime the committing will remove the message. Both actions are performed concurrently.
> 3. If the committing happens before the connection closing, transaction commit successfully and message won't get cancelled. But if the committing happens after connection closing, there is a chance the message is cancelled back to queue and  yet the transaction is committed successfully. So the message will be delivered twice.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 22:23:23 2011
From: jira-events at lists.jboss.org (Misty Stanley-Jones (JIRA))
Date: Mon, 11 Jul 2011 22:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1257) Command given in CLI
 help text is wrong
Message-ID: <540721485.47134.1310437403643.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Command given in CLI help text is wrong
---------------------------------------

                 Key: AS7-1257
                 URL: https://issues.jboss.org/browse/AS7-1257
             Project: Application Server 7
          Issue Type: Bug
          Components: Server
    Affects Versions: 7.0.0.CR1
            Reporter: Misty Stanley-Jones
            Assignee: Jason Greene


When you are logged into the Management CLI and you type "help", one of the example commands it gives is:


e.g. /subsystem=web/connector=http:read-resource(recursive=1)

The syntax of the command is really this:


/subsystem=web/connector=http:read-resource(recursive=true)


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 23:11:23 2011
From: jira-events at lists.jboss.org (Andrew Rubinger (JIRA))
Date: Mon, 11 Jul 2011 23:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-136) Set up URL Stream
 HandlerFactory in MC Server initialization
Message-ID: <31213845.47154.1310440283749.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Set up URL Stream HandlerFactory in MC Server initialization
------------------------------------------------------------

                 Key: JBBOOT-136
                 URL: https://issues.jboss.org/browse/JBBOOT-136
             Project: JBoss Bootstrap
          Issue Type: Task
          Components: impl-mc
            Reporter: Andrew Rubinger
            Assignee: Andrew Rubinger
             Fix For: 2.1.0-alpha-6
         Attachments: URL__setURLStreamHandlerFactory_patch__.patch

Setup the URL Stream Handler Factory as part of doInitialization.  Patch provided by Ales.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 11 23:11:23 2011
From: jira-events at lists.jboss.org (Andrew Rubinger (JIRA))
Date: Mon, 11 Jul 2011 23:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-136) Set up URL Stream
 HandlerFactory in MC Server initialization
In-Reply-To: <31213845.47154.1310440283749.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2134276853.47156.1310440283949.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Andrew Rubinger updated JBBOOT-136:
-----------------------------------

    Attachment: URL__setURLStreamHandlerFactory_patch__.patch


> Set up URL Stream HandlerFactory in MC Server initialization
> ------------------------------------------------------------
>
>                 Key: JBBOOT-136
>                 URL: https://issues.jboss.org/browse/JBBOOT-136
>             Project: JBoss Bootstrap
>          Issue Type: Task
>          Components: impl-mc
>            Reporter: Andrew Rubinger
>            Assignee: Andrew Rubinger
>             Fix For: 2.1.0-alpha-6
>
>         Attachments: URL__setURLStreamHandlerFactory_patch__.patch
>
>
> Setup the URL Stream Handler Factory as part of doInitialization.  Patch provided by Ales.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 01:58:24 2011
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Tue, 12 Jul 2011 01:58:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3129) Regression:
 Evaluator '==' does not support 'null' any more
Message-ID: <2140517741.47303.1310450304403.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Regression: Evaluator '==' does not support 'null' any more
-----------------------------------------------------------

                 Key: JBRULES-3129
                 URL: https://issues.jboss.org/browse/JBRULES-3129
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler
    Affects Versions: 5.2.0.Final
            Reporter: Wolfgang Laun
            Assignee: Mark Proctor
             Fix For: 5.2.1.Final


The DRL file given below causes these error messages (although it compiled and executed correctly in 5.1.1). 
=============================================================
Evaluator '==' does not support type 'null : [Rule name='rule1']

[DialectError message='Unable to wire compiled classes, probably related to compilation failures:[Error: unable to resolve method using strict-mode: java.lang.Object.a()]
[Near : {... list[0].a ....}]
                     ^
[Line: 1, Column: 9]']
=============================================================
import java.util.List

declare Three
  a : String
  b : String
  c : String
end

declare ListOfThree
  list : List
  clazz : Class
end

rule 'rule1'
when
    ListOfThree( list.size > 0 && list[0].a == null, $c: clazz );
then
    System.out.println( "rule1 " + $c.getSimpleName() );
end


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 02:12:23 2011
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Tue, 12 Jul 2011 02:12:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3130) Regression. Rule
 misfires due to constraint list[0].field1/2 in two rules
Message-ID: <1738544242.47343.1310451143652.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Regression. Rule misfires due to constraint list[0].field1/2 in two rules
-------------------------------------------------------------------------

                 Key: JBRULES-3130
                 URL: https://issues.jboss.org/browse/JBRULES-3130
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.2.0.Final
            Reporter: Wolfgang Laun
            Assignee: Mark Proctor
            Priority: Critical
             Fix For: 5.2.1.Final


A pair of constraints suich as list[0].a == null and list[0].b == null in two different rules causes one of the rules not to fire and the other one to fire erroneously (see results at the end).

Java:
================================================================
public class Three {
    private String a;
    private String b;
    private String c;
    public Three( String a, String b, String c ){
	this.a = a;
	this.b = b;
	this.c = c;
    }
    public String getA(){ return a; }
    public String getB(){ return b; }
    public String getC(){ return c; }
}
================================================================
import java.util.*;
public class ListOfThree {
    private List<Three> list;
    private Class<?> clazz;
    public ListOfThree( Three three, Class<?> clazz ){
	list = new ArrayList<Three>();
	list.add( three );
        this.clazz = clazz;
    }
    public List<Three> getList(){ return list; }
    public Class<?> getClazz(){	return clazz; }
}
================================================================
// Insertion of facts
        Three three = new Three( "a", "b", "c" );
        ListOfThree listof3 = new ListOfThree( three, java.lang.Object.class );
        kSession.insert( listof3 );
        three = new Three( "x", null, "z" );
        listof3 = new ListOfThree( three, java.lang.String.class );
        kSession.insert( listof3 );
        three = new Three( null, "q", "r" );
        listof3 = new ListOfThree( three, java.lang.Integer.class );
        kSession.insert( listof3 );
===================================================================
rule 'rule1'
############################  dialect "mvel"   ## does not matter
when
    ListOfThree( list[0].a == null, $c: clazz );
then
    System.out.println( "rule1 " + $c.getSimpleName() );
end

rule 'rule2'
############################  dialect "mvel"   ## does not matter
when
    ListOfThree( list[0].b == null, $c: clazz  );
then
    System.out.println( "rule2 " + $c.getSimpleName() );
end
=================================================================
Results:
rule2 Integer
rule1 Integer



--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 02:16:23 2011
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Tue, 12 Jul 2011 02:16:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-3130) Regression. Rule
 misfires due to constraint list[0].field1/2 in two rules
In-Reply-To: <1738544242.47343.1310451143652.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <916300388.47349.1310451383810.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Wolfgang Laun updated JBRULES-3130:
-----------------------------------

    Description: 
A pair of constraints suich as list[0].a == null and list[0].b == null in two different rules causes one of the rules not to fire and the other one to fire erroneously (see results at the end).

Java:
------------------------------------------------------------
public class Three {
    private String a;
    private String b;
    private String c;
    public Three( String a, String b, String c ){
	this.a = a;
	this.b = b;
	this.c = c;
    }
    public String getA(){ return a; }
    public String getB(){ return b; }
    public String getC(){ return c; }
}
---------------------------------------------------------------
import java.util.*;
public class ListOfThree {
    private List<Three> list;
    private Class<?> clazz;
    public ListOfThree( Three three, Class<?> clazz ){
	list = new ArrayList<Three>();
	list.add( three );
        this.clazz = clazz;
    }
    public List<Three> getList(){ return list; }
    public Class<?> getClazz(){	return clazz; }
}
----------------------------------------------------------------
// Insertion of facts
        Three three = new Three( "a", "b", "c" );
        ListOfThree listof3 = new ListOfThree( three, java.lang.Object.class );
        kSession.insert( listof3 );
        three = new Three( "x", null, "z" );
        listof3 = new ListOfThree( three, java.lang.String.class );
        kSession.insert( listof3 );
        three = new Three( null, "q", "r" );
        listof3 = new ListOfThree( three, java.lang.Integer.class );
        kSession.insert( listof3 );
--------------------------------------------------------------------------
rule 'rule1'
############################  dialect "mvel"   ## does not matter
when
    ListOfThree( list[0].a == null, $c: clazz );
then
    System.out.println( "rule1 " + $c.getSimpleName() );
end

rule 'rule2'
############################  dialect "mvel"   ## does not matter
when
    ListOfThree( list[0].b == null, $c: clazz  );
then
    System.out.println( "rule2 " + $c.getSimpleName() );
end
---------------------------------------------------------------
Results:
rule2 Integer
rule1 Integer



  was:
A pair of constraints suich as list[0].a == null and list[0].b == null in two different rules causes one of the rules not to fire and the other one to fire erroneously (see results at the end).

Java:
================================================================
public class Three {
    private String a;
    private String b;
    private String c;
    public Three( String a, String b, String c ){
	this.a = a;
	this.b = b;
	this.c = c;
    }
    public String getA(){ return a; }
    public String getB(){ return b; }
    public String getC(){ return c; }
}
================================================================
import java.util.*;
public class ListOfThree {
    private List<Three> list;
    private Class<?> clazz;
    public ListOfThree( Three three, Class<?> clazz ){
	list = new ArrayList<Three>();
	list.add( three );
        this.clazz = clazz;
    }
    public List<Three> getList(){ return list; }
    public Class<?> getClazz(){	return clazz; }
}
================================================================
// Insertion of facts
        Three three = new Three( "a", "b", "c" );
        ListOfThree listof3 = new ListOfThree( three, java.lang.Object.class );
        kSession.insert( listof3 );
        three = new Three( "x", null, "z" );
        listof3 = new ListOfThree( three, java.lang.String.class );
        kSession.insert( listof3 );
        three = new Three( null, "q", "r" );
        listof3 = new ListOfThree( three, java.lang.Integer.class );
        kSession.insert( listof3 );
===================================================================
rule 'rule1'
############################  dialect "mvel"   ## does not matter
when
    ListOfThree( list[0].a == null, $c: clazz );
then
    System.out.println( "rule1 " + $c.getSimpleName() );
end

rule 'rule2'
############################  dialect "mvel"   ## does not matter
when
    ListOfThree( list[0].b == null, $c: clazz  );
then
    System.out.println( "rule2 " + $c.getSimpleName() );
end
=================================================================
Results:
rule2 Integer
rule1 Integer





> Regression. Rule misfires due to constraint list[0].field1/2 in two rules
> -------------------------------------------------------------------------
>
>                 Key: JBRULES-3130
>                 URL: https://issues.jboss.org/browse/JBRULES-3130
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.2.0.Final
>            Reporter: Wolfgang Laun
>            Assignee: Mark Proctor
>            Priority: Critical
>             Fix For: 5.2.1.Final
>
>
> A pair of constraints suich as list[0].a == null and list[0].b == null in two different rules causes one of the rules not to fire and the other one to fire erroneously (see results at the end).
> Java:
> ------------------------------------------------------------
> public class Three {
>     private String a;
>     private String b;
>     private String c;
>     public Three( String a, String b, String c ){
> 	this.a = a;
> 	this.b = b;
> 	this.c = c;
>     }
>     public String getA(){ return a; }
>     public String getB(){ return b; }
>     public String getC(){ return c; }
> }
> ---------------------------------------------------------------
> import java.util.*;
> public class ListOfThree {
>     private List<Three> list;
>     private Class<?> clazz;
>     public ListOfThree( Three three, Class<?> clazz ){
> 	list = new ArrayList<Three>();
> 	list.add( three );
>         this.clazz = clazz;
>     }
>     public List<Three> getList(){ return list; }
>     public Class<?> getClazz(){	return clazz; }
> }
> ----------------------------------------------------------------
> // Insertion of facts
>         Three three = new Three( "a", "b", "c" );
>         ListOfThree listof3 = new ListOfThree( three, java.lang.Object.class );
>         kSession.insert( listof3 );
>         three = new Three( "x", null, "z" );
>         listof3 = new ListOfThree( three, java.lang.String.class );
>         kSession.insert( listof3 );
>         three = new Three( null, "q", "r" );
>         listof3 = new ListOfThree( three, java.lang.Integer.class );
>         kSession.insert( listof3 );
> --------------------------------------------------------------------------
> rule 'rule1'
> ############################  dialect "mvel"   ## does not matter
> when
>     ListOfThree( list[0].a == null, $c: clazz );
> then
>     System.out.println( "rule1 " + $c.getSimpleName() );
> end
> rule 'rule2'
> ############################  dialect "mvel"   ## does not matter
> when
>     ListOfThree( list[0].b == null, $c: clazz  );
> then
>     System.out.println( "rule2 " + $c.getSimpleName() );
> end
> ---------------------------------------------------------------
> Results:
> rule2 Integer
> rule1 Integer

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 02:18:23 2011
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Tue, 12 Jul 2011 02:18:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-3130) Regression. Rule
 misfires due to constraint list[0].field1/2 in two rules
In-Reply-To: <1738544242.47343.1310451143652.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1105622027.47352.1310451503670.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Wolfgang Laun updated JBRULES-3130:
-----------------------------------

    Description: 
A pair of constraints suich as list[0].a == null and list[0].b == null in two different rules causes one of the rules not to fire and the other one to fire erroneously (see results at the end).

Java:
------------------------------------------------------------
public class Three {
    private String a;
    private String b;
    private String c;
    public Three( String a, String b, String c ){
	this.a = a;
	this.b = b;
	this.c = c;
    }
    public String getA(){ return a; }
    public String getB(){ return b; }
    public String getC(){ return c; }
}
---------------------------------------------------------------
import java.util.*;
public class ListOfThree {
    private List<Three> list;
    private Class<?> clazz;
    public ListOfThree( Three three, Class<?> clazz ){
	list = new ArrayList<Three>();
	list.add( three );
        this.clazz = clazz;
    }
    public List<Three> getList(){ return list; }
    public Class<?> getClazz(){	return clazz; }
}
----------------------------------------------------------------
// Insertion of facts
        Three three = new Three( "a", "b", "c" );
        ListOfThree listof3 = new ListOfThree( three, java.lang.Object.class );
        kSession.insert( listof3 );
        three = new Three( "x", null, "z" );
        listof3 = new ListOfThree( three, java.lang.String.class );
        kSession.insert( listof3 );
        three = new Three( null, "q", "r" );
        listof3 = new ListOfThree( three, java.lang.Integer.class );
        kSession.insert( listof3 );
--------------------------------------------------------------------------
rule 'rule1'
//  dialect "mvel"   // does not matter
when
    ListOfThree( list[0].a == null, $c: clazz );
then
    System.out.println( "rule1 " + $c.getSimpleName() );
end

rule 'rule2'
//  dialect "mvel"   // does not matter
when
    ListOfThree( list[0].b == null, $c: clazz  );
then
    System.out.println( "rule2 " + $c.getSimpleName() );
end
---------------------------------------------------------------
Results:
rule2 Integer
rule1 Integer



  was:
A pair of constraints suich as list[0].a == null and list[0].b == null in two different rules causes one of the rules not to fire and the other one to fire erroneously (see results at the end).

Java:
------------------------------------------------------------
public class Three {
    private String a;
    private String b;
    private String c;
    public Three( String a, String b, String c ){
	this.a = a;
	this.b = b;
	this.c = c;
    }
    public String getA(){ return a; }
    public String getB(){ return b; }
    public String getC(){ return c; }
}
---------------------------------------------------------------
import java.util.*;
public class ListOfThree {
    private List<Three> list;
    private Class<?> clazz;
    public ListOfThree( Three three, Class<?> clazz ){
	list = new ArrayList<Three>();
	list.add( three );
        this.clazz = clazz;
    }
    public List<Three> getList(){ return list; }
    public Class<?> getClazz(){	return clazz; }
}
----------------------------------------------------------------
// Insertion of facts
        Three three = new Three( "a", "b", "c" );
        ListOfThree listof3 = new ListOfThree( three, java.lang.Object.class );
        kSession.insert( listof3 );
        three = new Three( "x", null, "z" );
        listof3 = new ListOfThree( three, java.lang.String.class );
        kSession.insert( listof3 );
        three = new Three( null, "q", "r" );
        listof3 = new ListOfThree( three, java.lang.Integer.class );
        kSession.insert( listof3 );
--------------------------------------------------------------------------
rule 'rule1'
############################  dialect "mvel"   ## does not matter
when
    ListOfThree( list[0].a == null, $c: clazz );
then
    System.out.println( "rule1 " + $c.getSimpleName() );
end

rule 'rule2'
############################  dialect "mvel"   ## does not matter
when
    ListOfThree( list[0].b == null, $c: clazz  );
then
    System.out.println( "rule2 " + $c.getSimpleName() );
end
---------------------------------------------------------------
Results:
rule2 Integer
rule1 Integer





> Regression. Rule misfires due to constraint list[0].field1/2 in two rules
> -------------------------------------------------------------------------
>
>                 Key: JBRULES-3130
>                 URL: https://issues.jboss.org/browse/JBRULES-3130
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.2.0.Final
>            Reporter: Wolfgang Laun
>            Assignee: Mark Proctor
>            Priority: Critical
>             Fix For: 5.2.1.Final
>
>
> A pair of constraints suich as list[0].a == null and list[0].b == null in two different rules causes one of the rules not to fire and the other one to fire erroneously (see results at the end).
> Java:
> ------------------------------------------------------------
> public class Three {
>     private String a;
>     private String b;
>     private String c;
>     public Three( String a, String b, String c ){
> 	this.a = a;
> 	this.b = b;
> 	this.c = c;
>     }
>     public String getA(){ return a; }
>     public String getB(){ return b; }
>     public String getC(){ return c; }
> }
> ---------------------------------------------------------------
> import java.util.*;
> public class ListOfThree {
>     private List<Three> list;
>     private Class<?> clazz;
>     public ListOfThree( Three three, Class<?> clazz ){
> 	list = new ArrayList<Three>();
> 	list.add( three );
>         this.clazz = clazz;
>     }
>     public List<Three> getList(){ return list; }
>     public Class<?> getClazz(){	return clazz; }
> }
> ----------------------------------------------------------------
> // Insertion of facts
>         Three three = new Three( "a", "b", "c" );
>         ListOfThree listof3 = new ListOfThree( three, java.lang.Object.class );
>         kSession.insert( listof3 );
>         three = new Three( "x", null, "z" );
>         listof3 = new ListOfThree( three, java.lang.String.class );
>         kSession.insert( listof3 );
>         three = new Three( null, "q", "r" );
>         listof3 = new ListOfThree( three, java.lang.Integer.class );
>         kSession.insert( listof3 );
> --------------------------------------------------------------------------
> rule 'rule1'
> //  dialect "mvel"   // does not matter
> when
>     ListOfThree( list[0].a == null, $c: clazz );
> then
>     System.out.println( "rule1 " + $c.getSimpleName() );
> end
> rule 'rule2'
> //  dialect "mvel"   // does not matter
> when
>     ListOfThree( list[0].b == null, $c: clazz  );
> then
>     System.out.println( "rule2 " + $c.getSimpleName() );
> end
> ---------------------------------------------------------------
> Results:
> rule2 Integer
> rule1 Integer

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 03:06:23 2011
From: jira-events at lists.jboss.org (Pontus Ullgren (JIRA))
Date: Tue, 12 Jul 2011 03:06:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-276) End of file new
 line in aliases.txt creates empty alias
Message-ID: <2045543350.47471.1310454383643.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

End of file new line in aliases.txt creates empty alias
-------------------------------------------------------

                 Key: JBDEPLOY-276
                 URL: https://issues.jboss.org/browse/JBDEPLOY-276
             Project: JBoss Deployers
          Issue Type: Bug
          Components: vfs
    Affects Versions: JBDEPLOY-2.2.1.GA
            Reporter: Pontus Ullgren
            Priority: Minor


A empty line in aliases.txt will result in a alias without name being created.
This becomes obvious when two modules happens to have a empty new line in the end of the aliases.txt file the result is then 
Caused by: java.lang.IllegalStateException: 
_Alias_AbstractKernelController[29048474] is already installed.
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)

My suggestion is to simply filter out any empty line in org.jboss.deployers.vfs.plugins.dependency.AliasesParserDeployer#parse(...).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 03:15:23 2011
From: jira-events at lists.jboss.org (Pontus Ullgren (JIRA))
Date: Tue, 12 Jul 2011 03:15:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBDEPLOY-276) End of file new
 line in aliases.txt creates empty alias
In-Reply-To: <2045543350.47471.1310454383643.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1512357642.47475.1310454923829.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Pontus Ullgren updated JBDEPLOY-276:
------------------------------------

    Attachment: JBDEPLOY-276.diff.gz


Here is a untested patch that should solve the problem. Untested since yet been unable to figure out howto build the package.

> End of file new line in aliases.txt creates empty alias
> -------------------------------------------------------
>
>                 Key: JBDEPLOY-276
>                 URL: https://issues.jboss.org/browse/JBDEPLOY-276
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: vfs
>    Affects Versions: JBDEPLOY-2.2.1.GA
>            Reporter: Pontus Ullgren
>            Priority: Minor
>         Attachments: JBDEPLOY-276.diff.gz
>
>
> A empty line in aliases.txt will result in a alias without name being created.
> This becomes obvious when two modules happens to have a empty new line in the end of the aliases.txt file the result is then 
> Caused by: java.lang.IllegalStateException: 
> _Alias_AbstractKernelController[29048474] is already installed.
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
> My suggestion is to simply filter out any empty line in org.jboss.deployers.vfs.plugins.dependency.AliasesParserDeployer#parse(...).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 03:22:23 2011
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Tue, 12 Jul 2011 03:22:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2951) regression:
 cannot compile return value "(java.lang.Object.class)"
In-Reply-To: <774445093.21798.1302601293046.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <19884788.47489.1310455343793.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Wolfgang Laun commented on JBRULES-2951:
----------------------------------------

Apparently you can write a comparison such as
   clazz == java.lang.Object
but you cannot write
   clazz == (java.lang.Object)
which is rather quirky. You can write 
   clazz == (java.lang.Object.class)
but not any more:
   clazz == java.lang.Object.class
Headache!

Note that the JIRA title says "regression...". I have code where 
   clazz == (java.lang.Object.class)
is used, which - alone - is accepted by 5.3.0 (which makes it even more confusing) but fails when combined with '||', e.g.
   clazz == null || clazz == (java.lang.Object.class)



> regression: cannot compile return value "(java.lang.Object.class)"
> ------------------------------------------------------------------
>
>                 Key: JBRULES-2951
>                 URL: https://issues.jboss.org/browse/JBRULES-2951
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler
>    Affects Versions: 5.2.0.M2
>            Reporter: Wolfgang Laun
>            Assignee: Mark Proctor
>            Priority: Critical
>
> The rule below compiled with a version build from HEAD on February 10, 2011. But now: 
> Unable to Analyse Expression target == source || target == (java.lang.Object.class):
> [Error: Failed to compile: 2 compilation error(s): 
>  - (1,32) unable to resolve method using strict-mode: ex10.Assignment.java()
>  - (1,32) unqualified type in strict mode for: java]
> [Near : {... target == source || target == (java.lang.Object.class) ....}]
>                                             ^
> [Line: 1, Column: 32] : [Rule name='SameOrObjectIsAssignable']
> ALSO please note that the line number is way off.
> rule SameOrObjectIsAssignable
> when
>     $a: Assignment( $t: target, target == source  || target == (java.lang.Object.class) )
> then
>     System.out.println( $a.toString() + " is OK. " );
>     retract( $a.getOriginal() );
> end

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 04:06:23 2011
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 12 Jul 2011 04:06:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1234) Hibernate does not
 read/use metadata for orm.xml defined entites
In-Reply-To: <461439061.42234.1310135790589.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <20797970.47539.1310457983717.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar commented on AS7-1234:
----------------------------------

Stuart Tnx, that did it!

For all together to work properly I had to also add hibernate and javassist dependancy (enhanced classes)
but in general that did it!

> Hibernate does not read/use metadata for orm.xml defined entites
> ----------------------------------------------------------------
>
>                 Key: AS7-1234
>                 URL: https://issues.jboss.org/browse/AS7-1234
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta3, 7.0.0.CR1, 7.0.0.Final, 7.0.1.Final, 7.1.0.Alpha1
>         Environment: windows 7, sql server 2008 r2
>            Reporter: Tomaz Cerar
>            Assignee: Stuart Douglas
>             Fix For: 7.0.0.Final
>
>         Attachments: module.zip, webapp-1.0.war
>
>
> I have setup where we have "common" entities defined in global lib/module that application(war/ear) in then dependent on.
> Then I declare this entities in orm.xml of my application just by class name.
> for instance:
> {code:xml}
> <entity class="com.company.module.Article"/>
> <entity class="com.company.module.Binary"/>
> <entity class="com.company.module.Category"/>
> {code}
> Up until as7/hibernate 4 this worked with no problems, but now it dies with exception "no id defined on entity Article". If I defined id in orm.xml it then finds id field but fails to find anything that is annotated on classes. 
> It looks like metadata is not read for this classes and hibernate sees them as just plain pojo with no annotations.
> I am guessing that problem has to do something with integration with AS7 that now has jandex index for all annotations...

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 04:32:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 12 Jul 2011 04:32:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1234) Hibernate does not
 read/use metadata for orm.xml defined entites
In-Reply-To: <461439061.42234.1310135790589.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1249871717.47564.1310459543851.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on AS7-1234:
-----------------------------------

Tomaz, this looks like an interesting usecase. Would you be able to write up what you did to get this working, in a wiki here http://community.jboss.org/en/jbossas/as7_users?view=documents?

> Hibernate does not read/use metadata for orm.xml defined entites
> ----------------------------------------------------------------
>
>                 Key: AS7-1234
>                 URL: https://issues.jboss.org/browse/AS7-1234
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta3, 7.0.0.CR1, 7.0.0.Final, 7.0.1.Final, 7.1.0.Alpha1
>         Environment: windows 7, sql server 2008 r2
>            Reporter: Tomaz Cerar
>            Assignee: Stuart Douglas
>             Fix For: 7.0.0.Final
>
>         Attachments: module.zip, webapp-1.0.war
>
>
> I have setup where we have "common" entities defined in global lib/module that application(war/ear) in then dependent on.
> Then I declare this entities in orm.xml of my application just by class name.
> for instance:
> {code:xml}
> <entity class="com.company.module.Article"/>
> <entity class="com.company.module.Binary"/>
> <entity class="com.company.module.Category"/>
> {code}
> Up until as7/hibernate 4 this worked with no problems, but now it dies with exception "no id defined on entity Article". If I defined id in orm.xml it then finds id field but fails to find anything that is annotated on classes. 
> It looks like metadata is not read for this classes and hibernate sees them as just plain pojo with no annotations.
> I am guessing that problem has to do something with integration with AS7 that now has jandex index for all annotations...

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 05:11:24 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 12 Jul 2011 05:11:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1026) Refactor
 extended persistence context
In-Reply-To: <31751186.1186472029340.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1489256150.47628.1310461884660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf resolved EJBTHREE-1026.
-------------------------------------

    Resolution: Out of Date


> Refactor extended persistence context
> -------------------------------------
>
>                 Key: EJBTHREE-1026
>                 URL: https://issues.jboss.org/browse/EJBTHREE-1026
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: AS 5.0.0.Beta3
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>            Priority: Critical
>             Fix For: Unscheduled
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 05:11:25 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 12 Jul 2011 05:11:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-1026) Refactor extended
 persistence context
In-Reply-To: <31751186.1186472029340.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1685240376.47637.1310461885070.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf closed EJBTHREE-1026.
-----------------------------------



> Refactor extended persistence context
> -------------------------------------
>
>                 Key: EJBTHREE-1026
>                 URL: https://issues.jboss.org/browse/EJBTHREE-1026
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: AS 5.0.0.Beta3
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>            Priority: Critical
>             Fix For: Unscheduled
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 05:11:25 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 12 Jul 2011 05:11:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (EJBTHREE-1026) Refactor
 extended persistence context
In-Reply-To: <31751186.1186472029340.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <730186954.47646.1310461885897.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf reopened EJBTHREE-1026:
-------------------------------------



> Refactor extended persistence context
> -------------------------------------
>
>                 Key: EJBTHREE-1026
>                 URL: https://issues.jboss.org/browse/EJBTHREE-1026
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: AS 5.0.0.Beta3
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>            Priority: Critical
>             Fix For: Unscheduled
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 05:13:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 12 Jul 2011 05:13:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-1026) Refactor
 extended persistence context
In-Reply-To: <31751186.1186472029340.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1661842973.47655.1310462003899.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf updated EJBTHREE-1026:
------------------------------------

    Fix Version/s:     (was: Unscheduled)


> Refactor extended persistence context
> -------------------------------------
>
>                 Key: EJBTHREE-1026
>                 URL: https://issues.jboss.org/browse/EJBTHREE-1026
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: AS 5.0.0.Beta3
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>            Priority: Critical
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 05:13:24 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 12 Jul 2011 05:13:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1026) Refactor
 extended persistence context
In-Reply-To: <31751186.1186472029340.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <565915571.47665.1310462004183.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf resolved EJBTHREE-1026.
-------------------------------------

    Resolution: Out of Date


> Refactor extended persistence context
> -------------------------------------
>
>                 Key: EJBTHREE-1026
>                 URL: https://issues.jboss.org/browse/EJBTHREE-1026
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: AS 5.0.0.Beta3
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>            Priority: Critical
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 05:13:24 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 12 Jul 2011 05:13:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-1026) Refactor extended
 persistence context
In-Reply-To: <31751186.1186472029340.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <956372878.47667.1310462004223.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf closed EJBTHREE-1026.
-----------------------------------



> Refactor extended persistence context
> -------------------------------------
>
>                 Key: EJBTHREE-1026
>                 URL: https://issues.jboss.org/browse/EJBTHREE-1026
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: AS 5.0.0.Beta3
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>            Priority: Critical
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 07:56:23 2011
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Tue, 12 Jul 2011 07:56:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3131) timer( cron: ...)
 causes ArrayStoreException with slightly erroneous (?) argument
Message-ID: <1761837893.47951.1310471783721.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

timer( cron: ...) causes ArrayStoreException with slightly erroneous (?) argument
---------------------------------------------------------------------------------

                 Key: JBRULES-3131
                 URL: https://issues.jboss.org/browse/JBRULES-3131
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler (expert)
    Affects Versions: 5.2.0.Final
            Reporter: Wolfgang Laun
            Assignee: Mark Proctor
             Fix For: 5.2.1.Final


rule xxx
timer( cron: 0/30 * * * * * )
when
then
end

Exception in thread "main" java.lang.ArrayStoreException
	at java.lang.System.arraycopy(Native Method)
	at java.util.ArrayList.toArray(ArrayList.java:306)
	at org.drools.compiler.PackageBuilder.getErrors(PackageBuilder.java:1274)
	at org.drools.builder.impl.KnowledgeBuilderImpl.getErrors(KnowledgeBuilderImpl.java:70)


It would be a Good Thing if timer( cron: ) were documented. It deviates from UNIX crontab in at least two aspects.





--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 08:04:23 2011
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Tue, 12 Jul 2011 08:04:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3132) Simple syntax
 error timer(int 10) causes RuntimeDroolsException in RuleBuilder
Message-ID: <524792743.47964.1310472263623.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Simple syntax error  timer(int 10) causes RuntimeDroolsException in RuleBuilder
-------------------------------------------------------------------------------

                 Key: JBRULES-3132
                 URL: https://issues.jboss.org/browse/JBRULES-3132
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.2.0.Final
            Reporter: Wolfgang Laun
            Assignee: Mark Proctor
             Fix For: 5.2.1.Final


rule xxx
timer(int 10 )  # not the missing colon
when
then
    System.out.println( "CRONTAB" );
end

causes:

Exception in thread "main" org.drools.RuntimeDroolsException: Error parsing time string: [ int ]
	at org.drools.time.TimeUtils.parseTimeString(TimeUtils.java:127)
	at org.drools.rule.builder.RuleBuilder.buildTimer(RuleBuilder.java:320)
	at org.drools.rule.builder.RuleBuilder.buildAttributes(RuleBuilder.java:139)
	at org.drools.rule.builder.RuleBuilder.build(RuleBuilder.java:92)
	at org.drools.compiler.PackageBuilder.addRule(PackageBuilder.java:1889)
	at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:755)
	at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:365)
	at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:543)
	at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:28)


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 08:14:23 2011
From: jira-events at lists.jboss.org (Michael Anstis (JIRA))
Date: Tue, 12 Jul 2011 08:14:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3133) Declarative
 types: Extending requires explicit import statement
Message-ID: <424947039.47992.1310472863995.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Declarative types: Extending requires explicit import statement
---------------------------------------------------------------

                 Key: JBRULES-3133
                 URL: https://issues.jboss.org/browse/JBRULES-3133
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler (expert)
    Affects Versions: 5.2.0.Final
            Reporter: Michael Anstis
            Assignee: Mark Proctor


Given Person class:-

{code}
package com.guvnor.domain;

import java.math.BigDecimal;

public class Person {

    private BigDecimal salary;

    public BigDecimal getSalary() {
        return salary;
    }

    public void setSalary(BigDecimal salary) {
        this.salary = salary;
    }

}
{code}

The following compiles OK:-

{code}
package com.sample
 
import com.guvnor.domain.Person

declare Person
end
{code}

However the following does not (without explicitly importing java.math.BigDecimal - which is a field type in Person):-

{code}
package com.sample
 
import com.guvnor.domain.Person
import com.guvnor.domain.Address

declare Person
end

declare Person2 extends Person
    flange : String
end
{code}

Error being "Unknown DroolsError class org.drools.compiler.TypeDeclarationError: Unable to find class 'BigDecimal' ".


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 08:14:24 2011
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Tue, 12 Jul 2011 08:14:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3134) Parenthesized
 class name causes NPE in RuleBuilder (MVEL)
Message-ID: <1359811706.48003.1310472864441.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Parenthesized class name causes NPE in RuleBuilder (MVEL)
---------------------------------------------------------

                 Key: JBRULES-3134
                 URL: https://issues.jboss.org/browse/JBRULES-3134
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.2.0.Final
            Reporter: Wolfgang Laun
            Assignee: Mark Proctor
             Fix For: 5.2.1.Final


declare Foo
  clazz : Class
end
rule testFoo
when
    Foo( clazz == (java.lang.Object)  )
then
    System.out.println( "Foo is Object" );
end

causes

Exception in thread "main" [Error: not a statement, or badly formed structure]
[Near : {... (java.lang.Object) ....}]
                               ^
[Line: 1, Column: 19]
	at org.mvel2.compiler.ExpressionCompiler._compile(ExpressionCompiler.java:307)
	at org.mvel2.compiler.ExpressionCompiler.compile(ExpressionCompiler.java:69)
	at org.mvel2.MVEL.analysisCompile(MVEL.java:668)
	at org.mvel2.MVEL.analysisCompile(MVEL.java:672)
	at org.drools.rule.builder.PatternBuilder.setInputs(PatternBuilder.java:779)
	at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:540)
	at org.drools.rule.builder.PatternBuilder.processConstraintsAndBinds(PatternBuilder.java:349)
	at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:264)
	at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:122)
	at org.drools.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:65)
	at org.drools.rule.builder.RuleBuilder.build(RuleBuilder.java:81)
	at org.drools.compiler.PackageBuilder.addRule(PackageBuilder.java:1889)
	at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:755)
	at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:365)
	at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:543)
	at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:28)
	at listofthree.Main.setup(Main.java:55)
	at listofthree.Main.main(Main.java:107)
Caused by: java.lang.NullPointerException
	at java.lang.Class.isAssignableFrom(Native Method)
	at org.mvel2.DataConversion.canConvert(DataConversion.java:104)
	at org.mvel2.ast.TypeCast.<init>(TypeCast.java:47)
	at org.mvel2.compiler.AbstractParser.nextToken(AbstractParser.java:1034)
	at org.mvel2.compiler.ExpressionCompiler._compile(ExpressionCompiler.java:135)
	... 17 more


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 08:26:23 2011
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Tue, 12 Jul 2011 08:26:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1258) required
 xa-data-source-properties is missing from add operation description
Message-ID: <1892072371.48008.1310473583620.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

required xa-data-source-properties is missing from add operation description
----------------------------------------------------------------------------

                 Key: AS7-1258
                 URL: https://issues.jboss.org/browse/AS7-1258
             Project: Application Server 7
          Issue Type: Bug
          Components: JCA
    Affects Versions: 7.0.0.CR1
            Reporter: Alexey Loubyansky
            Assignee: Stefano Maestri


xa-data-source-properties property is required by add operation but is missing from the operation description.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 08:28:23 2011
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Tue, 12 Jul 2011 08:28:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1259) remove
 add/modify/remove-[xa-]data-source commands
Message-ID: <884327167.48012.1310473703617.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

remove add/modify/remove-[xa-]data-source commands
--------------------------------------------------

                 Key: AS7-1259
                 URL: https://issues.jboss.org/browse/AS7-1259
             Project: Application Server 7
          Issue Type: Task
          Components: CLI
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky


These commands should be removed in favour of the generic type commands data-source and xa-data-source.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 09:42:23 2011
From: jira-events at lists.jboss.org (Trustin Lee (JIRA))
Date: Tue, 12 Jul 2011 09:42:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1260) JGroups subsystem
 fails to setup some protocol stacks.
Message-ID: <1568744513.48245.1310478143759.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

JGroups subsystem fails to setup some protocol stacks.
------------------------------------------------------

                 Key: AS7-1260
                 URL: https://issues.jboss.org/browse/AS7-1260
             Project: Application Server 7
          Issue Type: Bug
            Reporter: Trustin Lee
            Assignee: Paul Ferraro
            Priority: Critical


After upgrading from AS 7.0.0.CR1 to AS 7.0.0.Final, I started to see an exception raised by org.jboss.as.clustering.jgroups.JChannelFactory:

{code}
22:11:54,040 ERROR [stderr] (MSC service thread 1-1) java.lang.IllegalArgumentException: org.jgroups.ChannelException: unable to setup the protocol stack
22:11:54,040 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.ChannelProvider.getJGroupsChannel(ChannelProvider.java:71)
22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:273)
22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:226)
22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:254)
22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:148)
22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at java.lang.reflect.Method.invoke(Method.java:597)
22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:918)
22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:711)
22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:611)
22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:176)
22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:171)
22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.CacheImpl.start(CacheImpl.java:366)
22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:559)
22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:479)
22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:84)
22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:73)
22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:73)
22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at java.lang.Thread.run(Thread.java:680)
22:11:54,045 ERROR [stderr] (MSC service thread 1-1) Caused by: org.jgroups.ChannelException: unable to setup the protocol stack
22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.init(JChannel.java:1728)
22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.<init>(JChannel.java:249)
22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.jgroups.JChannelFactory$JChannel.<init>(JChannelFactory.java:269)
22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:69)
22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.ChannelProvider.getJGroupsChannel(ChannelProvider.java:67)
22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	... 26 more
22:11:54,046 ERROR [stderr] (MSC service thread 1-1) Caused by: java.lang.IllegalArgumentException: the following properties in PING are not recognized: {bind_addr=192.168.0.196}
22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.createLayer(Configurator.java:460)
22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.createProtocols(Configurator.java:393)
22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:88)
22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:55)
22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:534)
22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.init(JChannel.java:1725)
22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	... 30 more
{code}

(Actually, the exception was being swallowed by Infinispan, so I had to modify the source code in Infinispan.)

Reverting back only the JGroups subsystem to 7.0.0.CR1 fixes the problem.  The offending subsystem configuration is:

{code}
        <subsystem xmlns="urn:jboss:domain:jgroups:1.0" default-stack="udp">
            <stack name="udp">
                <transport type="UDP"
                           socket-binding="jgroups-udp"
                           default-executor="jgroups"
                           oob-executor="jgroups-oob"
                           timer-executor="jgroups-timer"/>
                <protocol type="PING"/>
                <protocol type="MERGE2"/>
                <protocol type="FD_SOCK"/>
                <protocol type="FD"/>
                <protocol type="VERIFY_SUSPECT"/>
                <protocol type="BARRIER"/>
                <protocol type="pbcast.NAKACK"/>
                <protocol type="UNICAST"/>
                <protocol type="pbcast.STABLE"/>
                <protocol type="VIEW_SYNC"/>
                <protocol type="pbcast.GMS"/>
                <protocol type="UFC"/>
                <protocol type="MFC"/>
                <protocol type="FRAG2"/>
                <protocol type="pbcast.STREAMING_STATE_TRANSFER"/>
                <protocol type="pbcast.FLUSH"/>
            </stack>
            <stack name="tcp">
                <transport type="TCP"
                           socket-binding="jgroups-tcp"
                           default-executor="jgroups"
                           oob-executor="jgroups-oob"
                           timer-executor="jgroups-timer"/>
                <protocol type="MPING" socket-binding="jgroups-mping"/>
                <protocol type="MERGE2"/>
                <protocol type="FD_SOCK"/>
                <protocol type="FD"/>
                <protocol type="VERIFY_SUSPECT"/>
                <protocol type="BARRIER"/>
                <protocol type="pbcast.NAKACK"/>
                <protocol type="UNICAST"/>
                <protocol type="pbcast.STABLE"/>
                <protocol type="VIEW_SYNC"/>
                <protocol type="pbcast.GMS"/>
                <protocol type="UFC"/>
                <protocol type="MFC"/>
                <protocol type="FRAG2"/>
                <protocol type="pbcast.STREAMING_STATE_TRANSFER"/>
                <protocol type="pbcast.FLUSH"/>
            </stack>
        </subsystem>
{code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 09:42:24 2011
From: jira-events at lists.jboss.org (Trustin Lee (JIRA))
Date: Tue, 12 Jul 2011 09:42:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1260) JGroups subsystem
 fails to setup some protocol stacks.
In-Reply-To: <1568744513.48245.1310478143759.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1645924267.48250.1310478144208.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Trustin Lee updated AS7-1260:
-----------------------------

    Affects Version/s: 7.0.0.Final
          Component/s: Clustering


> JGroups subsystem fails to setup some protocol stacks.
> ------------------------------------------------------
>
>                 Key: AS7-1260
>                 URL: https://issues.jboss.org/browse/AS7-1260
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.Final
>            Reporter: Trustin Lee
>            Assignee: Paul Ferraro
>            Priority: Critical
>
> After upgrading from AS 7.0.0.CR1 to AS 7.0.0.Final, I started to see an exception raised by org.jboss.as.clustering.jgroups.JChannelFactory:
> {code}
> 22:11:54,040 ERROR [stderr] (MSC service thread 1-1) java.lang.IllegalArgumentException: org.jgroups.ChannelException: unable to setup the protocol stack
> 22:11:54,040 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.ChannelProvider.getJGroupsChannel(ChannelProvider.java:71)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:273)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:226)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:254)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:148)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at java.lang.reflect.Method.invoke(Method.java:597)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:918)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:711)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:611)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:176)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:171)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.CacheImpl.start(CacheImpl.java:366)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:559)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:479)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:84)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:73)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:73)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at java.lang.Thread.run(Thread.java:680)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) Caused by: org.jgroups.ChannelException: unable to setup the protocol stack
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.init(JChannel.java:1728)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.<init>(JChannel.java:249)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.jgroups.JChannelFactory$JChannel.<init>(JChannelFactory.java:269)
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:69)
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.ChannelProvider.getJGroupsChannel(ChannelProvider.java:67)
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	... 26 more
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) Caused by: java.lang.IllegalArgumentException: the following properties in PING are not recognized: {bind_addr=192.168.0.196}
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.createLayer(Configurator.java:460)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.createProtocols(Configurator.java:393)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:88)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:55)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:534)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.init(JChannel.java:1725)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	... 30 more
> {code}
> (Actually, the exception was being swallowed by Infinispan, so I had to modify the source code in Infinispan.)
> Reverting back only the JGroups subsystem to 7.0.0.CR1 fixes the problem.  The offending subsystem configuration is:
> {code}
>         <subsystem xmlns="urn:jboss:domain:jgroups:1.0" default-stack="udp">
>             <stack name="udp">
>                 <transport type="UDP"
>                            socket-binding="jgroups-udp"
>                            default-executor="jgroups"
>                            oob-executor="jgroups-oob"
>                            timer-executor="jgroups-timer"/>
>                 <protocol type="PING"/>
>                 <protocol type="MERGE2"/>
>                 <protocol type="FD_SOCK"/>
>                 <protocol type="FD"/>
>                 <protocol type="VERIFY_SUSPECT"/>
>                 <protocol type="BARRIER"/>
>                 <protocol type="pbcast.NAKACK"/>
>                 <protocol type="UNICAST"/>
>                 <protocol type="pbcast.STABLE"/>
>                 <protocol type="VIEW_SYNC"/>
>                 <protocol type="pbcast.GMS"/>
>                 <protocol type="UFC"/>
>                 <protocol type="MFC"/>
>                 <protocol type="FRAG2"/>
>                 <protocol type="pbcast.STREAMING_STATE_TRANSFER"/>
>                 <protocol type="pbcast.FLUSH"/>
>             </stack>
>             <stack name="tcp">
>                 <transport type="TCP"
>                            socket-binding="jgroups-tcp"
>                            default-executor="jgroups"
>                            oob-executor="jgroups-oob"
>                            timer-executor="jgroups-timer"/>
>                 <protocol type="MPING" socket-binding="jgroups-mping"/>
>                 <protocol type="MERGE2"/>
>                 <protocol type="FD_SOCK"/>
>                 <protocol type="FD"/>
>                 <protocol type="VERIFY_SUSPECT"/>
>                 <protocol type="BARRIER"/>
>                 <protocol type="pbcast.NAKACK"/>
>                 <protocol type="UNICAST"/>
>                 <protocol type="pbcast.STABLE"/>
>                 <protocol type="VIEW_SYNC"/>
>                 <protocol type="pbcast.GMS"/>
>                 <protocol type="UFC"/>
>                 <protocol type="MFC"/>
>                 <protocol type="FRAG2"/>
>                 <protocol type="pbcast.STREAMING_STATE_TRANSFER"/>
>                 <protocol type="pbcast.FLUSH"/>
>             </stack>
>         </subsystem>
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 10:01:24 2011
From: jira-events at lists.jboss.org (Trustin Lee (JIRA))
Date: Tue, 12 Jul 2011 10:01:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1260) JGroups subsystem
 fails to setup some protocol stacks.
In-Reply-To: <1568744513.48245.1310478143759.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1875210699.48307.1310479284061.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Trustin Lee commented on AS7-1260:
----------------------------------

It seems like the regression occurred while fixing AS7-1214.

> JGroups subsystem fails to setup some protocol stacks.
> ------------------------------------------------------
>
>                 Key: AS7-1260
>                 URL: https://issues.jboss.org/browse/AS7-1260
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.Final
>            Reporter: Trustin Lee
>            Assignee: Paul Ferraro
>            Priority: Critical
>
> After upgrading from AS 7.0.0.CR1 to AS 7.0.0.Final, I started to see an exception raised by org.jboss.as.clustering.jgroups.JChannelFactory:
> {code}
> 22:11:54,040 ERROR [stderr] (MSC service thread 1-1) java.lang.IllegalArgumentException: org.jgroups.ChannelException: unable to setup the protocol stack
> 22:11:54,040 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.ChannelProvider.getJGroupsChannel(ChannelProvider.java:71)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:273)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:226)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:254)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:148)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at java.lang.reflect.Method.invoke(Method.java:597)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:918)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:711)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:611)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:176)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:171)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.CacheImpl.start(CacheImpl.java:366)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:559)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:479)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:84)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:73)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:73)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at java.lang.Thread.run(Thread.java:680)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) Caused by: org.jgroups.ChannelException: unable to setup the protocol stack
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.init(JChannel.java:1728)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.<init>(JChannel.java:249)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.jgroups.JChannelFactory$JChannel.<init>(JChannelFactory.java:269)
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:69)
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.ChannelProvider.getJGroupsChannel(ChannelProvider.java:67)
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	... 26 more
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) Caused by: java.lang.IllegalArgumentException: the following properties in PING are not recognized: {bind_addr=192.168.0.196}
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.createLayer(Configurator.java:460)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.createProtocols(Configurator.java:393)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:88)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:55)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:534)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.init(JChannel.java:1725)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	... 30 more
> {code}
> (Actually, the exception was being swallowed by Infinispan, so I had to modify the source code in Infinispan.)
> Reverting back only the JGroups subsystem to 7.0.0.CR1 fixes the problem.  The offending subsystem configuration is:
> {code}
>         <subsystem xmlns="urn:jboss:domain:jgroups:1.0" default-stack="udp">
>             <stack name="udp">
>                 <transport type="UDP"
>                            socket-binding="jgroups-udp"
>                            default-executor="jgroups"
>                            oob-executor="jgroups-oob"
>                            timer-executor="jgroups-timer"/>
>                 <protocol type="PING"/>
>                 <protocol type="MERGE2"/>
>                 <protocol type="FD_SOCK"/>
>                 <protocol type="FD"/>
>                 <protocol type="VERIFY_SUSPECT"/>
>                 <protocol type="BARRIER"/>
>                 <protocol type="pbcast.NAKACK"/>
>                 <protocol type="UNICAST"/>
>                 <protocol type="pbcast.STABLE"/>
>                 <protocol type="VIEW_SYNC"/>
>                 <protocol type="pbcast.GMS"/>
>                 <protocol type="UFC"/>
>                 <protocol type="MFC"/>
>                 <protocol type="FRAG2"/>
>                 <protocol type="pbcast.STREAMING_STATE_TRANSFER"/>
>                 <protocol type="pbcast.FLUSH"/>
>             </stack>
>             <stack name="tcp">
>                 <transport type="TCP"
>                            socket-binding="jgroups-tcp"
>                            default-executor="jgroups"
>                            oob-executor="jgroups-oob"
>                            timer-executor="jgroups-timer"/>
>                 <protocol type="MPING" socket-binding="jgroups-mping"/>
>                 <protocol type="MERGE2"/>
>                 <protocol type="FD_SOCK"/>
>                 <protocol type="FD"/>
>                 <protocol type="VERIFY_SUSPECT"/>
>                 <protocol type="BARRIER"/>
>                 <protocol type="pbcast.NAKACK"/>
>                 <protocol type="UNICAST"/>
>                 <protocol type="pbcast.STABLE"/>
>                 <protocol type="VIEW_SYNC"/>
>                 <protocol type="pbcast.GMS"/>
>                 <protocol type="UFC"/>
>                 <protocol type="MFC"/>
>                 <protocol type="FRAG2"/>
>                 <protocol type="pbcast.STREAMING_STATE_TRANSFER"/>
>                 <protocol type="pbcast.FLUSH"/>
>             </stack>
>         </subsystem>
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 10:36:27 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 12 Jul 2011 10:36:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1261) Incorrect
 socket-binding-group for server-three in standard host.xml
Message-ID: <496404154.48446.1310481387575.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Incorrect socket-binding-group for server-three in standard host.xml
--------------------------------------------------------------------

                 Key: AS7-1261
                 URL: https://issues.jboss.org/browse/AS7-1261
             Project: Application Server 7
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 7.0.0.Final
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor
             Fix For: 7.0.1.Final


The config for the disabled-by-default server-three in host.xml references "standard-sockets" but "ha-sockets" is needed since the server is running the "ha" profile.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 10:44:23 2011
From: jira-events at lists.jboss.org (Trustin Lee (JIRA))
Date: Tue, 12 Jul 2011 10:44:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1260) JGroups subsystem
 fails to setup some protocol stacks.
In-Reply-To: <1568744513.48245.1310478143759.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <362812830.48474.1310481863787.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Trustin Lee updated AS7-1260:
-----------------------------

    Description: 
After upgrading from AS 7.0.0.CR1 to AS 7.0.0.Final, I started to see an exception raised by org.jboss.as.clustering.jgroups.JChannelFactory:

{code}
22:11:54,040 ERROR [stderr] (MSC service thread 1-1) java.lang.IllegalArgumentException: org.jgroups.ChannelException: unable to setup the protocol stack
22:11:54,040 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.ChannelProvider.getJGroupsChannel(ChannelProvider.java:71)
22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:273)
22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:226)
22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:254)
22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:148)
22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at java.lang.reflect.Method.invoke(Method.java:597)
22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:918)
22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:711)
22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:611)
22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:176)
22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:171)
22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.CacheImpl.start(CacheImpl.java:366)
22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:559)
22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:479)
22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:84)
22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:73)
22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:73)
22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at java.lang.Thread.run(Thread.java:680)
22:11:54,045 ERROR [stderr] (MSC service thread 1-1) Caused by: org.jgroups.ChannelException: unable to setup the protocol stack
22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.init(JChannel.java:1728)
22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.<init>(JChannel.java:249)
22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.jgroups.JChannelFactory$JChannel.<init>(JChannelFactory.java:269)
22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:69)
22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.ChannelProvider.getJGroupsChannel(ChannelProvider.java:67)
22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	... 26 more
22:11:54,046 ERROR [stderr] (MSC service thread 1-1) Caused by: java.lang.IllegalArgumentException: the following properties in PING are not recognized: {bind_addr=192.168.0.196}
22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.createLayer(Configurator.java:460)
22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.createProtocols(Configurator.java:393)
22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:88)
22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:55)
22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:534)
22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.init(JChannel.java:1725)
22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	... 30 more
{code}

(Actually, the exception was being swallowed by Infinispan, so I had to modify the source code in Infinispan.)

Reverting back only the JGroups subsystem to 7.0.0.CR1 fixes the problem for UDP stack.  TCP stack still fails when configuring MPING:

{code}
23:40:07,623 ERROR [stderr] (MSC service thread 1-8) Caused by: java.lang.IllegalArgumentException: the following properties in MPING are not recognized: {start_port=0}
23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.createLayer(Configurator.java:460)
23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.createProtocols(Configurator.java:393)
23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:88)
23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:55)
23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:534)
23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.JChannel.init(JChannel.java:1725)
23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	... 30 more
{code}

The offending subsystem configuration is:

{code}
        <subsystem xmlns="urn:jboss:domain:jgroups:1.0" default-stack="udp">
            <stack name="udp">
                <transport type="UDP"
                           socket-binding="jgroups-udp"
                           default-executor="jgroups"
                           oob-executor="jgroups-oob"
                           timer-executor="jgroups-timer"/>
                <protocol type="PING"/>
                <protocol type="MERGE2"/>
                <protocol type="FD_SOCK"/>
                <protocol type="FD"/>
                <protocol type="VERIFY_SUSPECT"/>
                <protocol type="BARRIER"/>
                <protocol type="pbcast.NAKACK"/>
                <protocol type="UNICAST"/>
                <protocol type="pbcast.STABLE"/>
                <protocol type="VIEW_SYNC"/>
                <protocol type="pbcast.GMS"/>
                <protocol type="UFC"/>
                <protocol type="MFC"/>
                <protocol type="FRAG2"/>
                <protocol type="pbcast.STREAMING_STATE_TRANSFER"/>
                <protocol type="pbcast.FLUSH"/>
            </stack>
            <stack name="tcp">
                <transport type="TCP"
                           socket-binding="jgroups-tcp"
                           default-executor="jgroups"
                           oob-executor="jgroups-oob"
                           timer-executor="jgroups-timer"/>
                <protocol type="MPING" socket-binding="jgroups-mping"/>
                <protocol type="MERGE2"/>
                <protocol type="FD_SOCK"/>
                <protocol type="FD"/>
                <protocol type="VERIFY_SUSPECT"/>
                <protocol type="BARRIER"/>
                <protocol type="pbcast.NAKACK"/>
                <protocol type="UNICAST"/>
                <protocol type="pbcast.STABLE"/>
                <protocol type="VIEW_SYNC"/>
                <protocol type="pbcast.GMS"/>
                <protocol type="UFC"/>
                <protocol type="MFC"/>
                <protocol type="FRAG2"/>
                <protocol type="pbcast.STREAMING_STATE_TRANSFER"/>
                <protocol type="pbcast.FLUSH"/>
            </stack>
        </subsystem>
{code}

  was:
After upgrading from AS 7.0.0.CR1 to AS 7.0.0.Final, I started to see an exception raised by org.jboss.as.clustering.jgroups.JChannelFactory:

{code}
22:11:54,040 ERROR [stderr] (MSC service thread 1-1) java.lang.IllegalArgumentException: org.jgroups.ChannelException: unable to setup the protocol stack
22:11:54,040 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.ChannelProvider.getJGroupsChannel(ChannelProvider.java:71)
22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:273)
22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:226)
22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:254)
22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:148)
22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at java.lang.reflect.Method.invoke(Method.java:597)
22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:918)
22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:711)
22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:611)
22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:176)
22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:171)
22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.CacheImpl.start(CacheImpl.java:366)
22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:559)
22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:479)
22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:84)
22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:73)
22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:73)
22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at java.lang.Thread.run(Thread.java:680)
22:11:54,045 ERROR [stderr] (MSC service thread 1-1) Caused by: org.jgroups.ChannelException: unable to setup the protocol stack
22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.init(JChannel.java:1728)
22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.<init>(JChannel.java:249)
22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.jgroups.JChannelFactory$JChannel.<init>(JChannelFactory.java:269)
22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:69)
22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.ChannelProvider.getJGroupsChannel(ChannelProvider.java:67)
22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	... 26 more
22:11:54,046 ERROR [stderr] (MSC service thread 1-1) Caused by: java.lang.IllegalArgumentException: the following properties in PING are not recognized: {bind_addr=192.168.0.196}
22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.createLayer(Configurator.java:460)
22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.createProtocols(Configurator.java:393)
22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:88)
22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:55)
22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:534)
22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.init(JChannel.java:1725)
22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	... 30 more
{code}

(Actually, the exception was being swallowed by Infinispan, so I had to modify the source code in Infinispan.)

Reverting back only the JGroups subsystem to 7.0.0.CR1 fixes the problem.  The offending subsystem configuration is:

{code}
        <subsystem xmlns="urn:jboss:domain:jgroups:1.0" default-stack="udp">
            <stack name="udp">
                <transport type="UDP"
                           socket-binding="jgroups-udp"
                           default-executor="jgroups"
                           oob-executor="jgroups-oob"
                           timer-executor="jgroups-timer"/>
                <protocol type="PING"/>
                <protocol type="MERGE2"/>
                <protocol type="FD_SOCK"/>
                <protocol type="FD"/>
                <protocol type="VERIFY_SUSPECT"/>
                <protocol type="BARRIER"/>
                <protocol type="pbcast.NAKACK"/>
                <protocol type="UNICAST"/>
                <protocol type="pbcast.STABLE"/>
                <protocol type="VIEW_SYNC"/>
                <protocol type="pbcast.GMS"/>
                <protocol type="UFC"/>
                <protocol type="MFC"/>
                <protocol type="FRAG2"/>
                <protocol type="pbcast.STREAMING_STATE_TRANSFER"/>
                <protocol type="pbcast.FLUSH"/>
            </stack>
            <stack name="tcp">
                <transport type="TCP"
                           socket-binding="jgroups-tcp"
                           default-executor="jgroups"
                           oob-executor="jgroups-oob"
                           timer-executor="jgroups-timer"/>
                <protocol type="MPING" socket-binding="jgroups-mping"/>
                <protocol type="MERGE2"/>
                <protocol type="FD_SOCK"/>
                <protocol type="FD"/>
                <protocol type="VERIFY_SUSPECT"/>
                <protocol type="BARRIER"/>
                <protocol type="pbcast.NAKACK"/>
                <protocol type="UNICAST"/>
                <protocol type="pbcast.STABLE"/>
                <protocol type="VIEW_SYNC"/>
                <protocol type="pbcast.GMS"/>
                <protocol type="UFC"/>
                <protocol type="MFC"/>
                <protocol type="FRAG2"/>
                <protocol type="pbcast.STREAMING_STATE_TRANSFER"/>
                <protocol type="pbcast.FLUSH"/>
            </stack>
        </subsystem>
{code}



> JGroups subsystem fails to setup some protocol stacks.
> ------------------------------------------------------
>
>                 Key: AS7-1260
>                 URL: https://issues.jboss.org/browse/AS7-1260
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.Final
>            Reporter: Trustin Lee
>            Assignee: Paul Ferraro
>            Priority: Critical
>
> After upgrading from AS 7.0.0.CR1 to AS 7.0.0.Final, I started to see an exception raised by org.jboss.as.clustering.jgroups.JChannelFactory:
> {code}
> 22:11:54,040 ERROR [stderr] (MSC service thread 1-1) java.lang.IllegalArgumentException: org.jgroups.ChannelException: unable to setup the protocol stack
> 22:11:54,040 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.ChannelProvider.getJGroupsChannel(ChannelProvider.java:71)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:273)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:226)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:254)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:148)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at java.lang.reflect.Method.invoke(Method.java:597)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:918)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:711)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:611)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:176)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:171)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.CacheImpl.start(CacheImpl.java:366)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:559)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:479)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:84)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:73)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:73)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at java.lang.Thread.run(Thread.java:680)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) Caused by: org.jgroups.ChannelException: unable to setup the protocol stack
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.init(JChannel.java:1728)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.<init>(JChannel.java:249)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.jgroups.JChannelFactory$JChannel.<init>(JChannelFactory.java:269)
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:69)
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.ChannelProvider.getJGroupsChannel(ChannelProvider.java:67)
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	... 26 more
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) Caused by: java.lang.IllegalArgumentException: the following properties in PING are not recognized: {bind_addr=192.168.0.196}
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.createLayer(Configurator.java:460)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.createProtocols(Configurator.java:393)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:88)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:55)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:534)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.init(JChannel.java:1725)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	... 30 more
> {code}
> (Actually, the exception was being swallowed by Infinispan, so I had to modify the source code in Infinispan.)
> Reverting back only the JGroups subsystem to 7.0.0.CR1 fixes the problem for UDP stack.  TCP stack still fails when configuring MPING:
> {code}
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) Caused by: java.lang.IllegalArgumentException: the following properties in MPING are not recognized: {start_port=0}
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.createLayer(Configurator.java:460)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.createProtocols(Configurator.java:393)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:88)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:55)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:534)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.JChannel.init(JChannel.java:1725)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	... 30 more
> {code}
> The offending subsystem configuration is:
> {code}
>         <subsystem xmlns="urn:jboss:domain:jgroups:1.0" default-stack="udp">
>             <stack name="udp">
>                 <transport type="UDP"
>                            socket-binding="jgroups-udp"
>                            default-executor="jgroups"
>                            oob-executor="jgroups-oob"
>                            timer-executor="jgroups-timer"/>
>                 <protocol type="PING"/>
>                 <protocol type="MERGE2"/>
>                 <protocol type="FD_SOCK"/>
>                 <protocol type="FD"/>
>                 <protocol type="VERIFY_SUSPECT"/>
>                 <protocol type="BARRIER"/>
>                 <protocol type="pbcast.NAKACK"/>
>                 <protocol type="UNICAST"/>
>                 <protocol type="pbcast.STABLE"/>
>                 <protocol type="VIEW_SYNC"/>
>                 <protocol type="pbcast.GMS"/>
>                 <protocol type="UFC"/>
>                 <protocol type="MFC"/>
>                 <protocol type="FRAG2"/>
>                 <protocol type="pbcast.STREAMING_STATE_TRANSFER"/>
>                 <protocol type="pbcast.FLUSH"/>
>             </stack>
>             <stack name="tcp">
>                 <transport type="TCP"
>                            socket-binding="jgroups-tcp"
>                            default-executor="jgroups"
>                            oob-executor="jgroups-oob"
>                            timer-executor="jgroups-timer"/>
>                 <protocol type="MPING" socket-binding="jgroups-mping"/>
>                 <protocol type="MERGE2"/>
>                 <protocol type="FD_SOCK"/>
>                 <protocol type="FD"/>
>                 <protocol type="VERIFY_SUSPECT"/>
>                 <protocol type="BARRIER"/>
>                 <protocol type="pbcast.NAKACK"/>
>                 <protocol type="UNICAST"/>
>                 <protocol type="pbcast.STABLE"/>
>                 <protocol type="VIEW_SYNC"/>
>                 <protocol type="pbcast.GMS"/>
>                 <protocol type="UFC"/>
>                 <protocol type="MFC"/>
>                 <protocol type="FRAG2"/>
>                 <protocol type="pbcast.STREAMING_STATE_TRANSFER"/>
>                 <protocol type="pbcast.FLUSH"/>
>             </stack>
>         </subsystem>
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 10:57:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 12 Jul 2011 10:57:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1261) Incorrect
 socket-binding-group for server-three in standard host.xml
In-Reply-To: <496404154.48446.1310481387575.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <989041354.48510.1310482643641.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry resolved AS7-1261.
-----------------------------------

    Resolution: Done


> Incorrect socket-binding-group for server-three in standard host.xml
> --------------------------------------------------------------------
>
>                 Key: AS7-1261
>                 URL: https://issues.jboss.org/browse/AS7-1261
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: 7.0.1.Final
>
>
> The config for the disabled-by-default server-three in host.xml references "standard-sockets" but "ha-sockets" is needed since the server is running the "ha" profile.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 11:01:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 12 Jul 2011 11:01:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-626) JBoss LogManager
	1.2.0.GA
Message-ID: <1541417362.48528.1310482883950.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

JBoss LogManager 1.2.0.GA
-------------------------

                 Key: JBJCA-626
                 URL: https://issues.jboss.org/browse/JBJCA-626
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.1.0.Alpha1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 11:32:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 12 Jul 2011 11:32:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-712) Publish all
 org.jboss.domain.* schemas to http://www.jboss.org/schema/
In-Reply-To: <260965286.28241.1304436318263.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <989568004.48776.1310484743682.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-712:
---------------------------------

    Comment: was deleted

(was: A comment with security level 'Red Hat' was removed.)


> Publish all org.jboss.domain.* schemas to http://www.jboss.org/schema/
> ----------------------------------------------------------------------
>
>                 Key: AS7-712
>                 URL: https://issues.jboss.org/browse/AS7-712
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Priority: Blocker
>             Fix For: 7.0.0.Final
>
>
> http://community.jboss.org/wiki/JBossDTDs

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 11:54:23 2011
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Tue, 12 Jul 2011 11:54:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1262) jboss-web.xsd needs
	updates
Message-ID: <1444077343.48856.1310486063795.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

jboss-web.xsd needs updates
---------------------------

                 Key: AS7-1262
                 URL: https://issues.jboss.org/browse/AS7-1262
             Project: Application Server 7
          Issue Type: Bug
          Components: Web
    Affects Versions: 7.0.0.Final
            Reporter: Anil Saldhana
            Assignee: Jean-Frederic Clere


As an example, the valve type is missing.  Unless we get to see some sample usage of jboss-web.xml, it will be difficult to understand what the configuration possibilities for jboss-web.xml exist.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 11:56:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 12 Jul 2011 11:56:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1263) Publish deployment
 descriptor schemas and dtd in the dist
Message-ID: <2078190816.48861.1310486183622.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Publish deployment descriptor schemas and dtd in the dist
---------------------------------------------------------

                 Key: AS7-1263
                 URL: https://issues.jboss.org/browse/AS7-1263
             Project: Application Server 7
          Issue Type: Task
    Affects Versions: 7.0.0.Final
            Reporter: Brian Stansberry
             Fix For: 7.0.1.Final


AS 7.0 has the domain/host/standalone config schemas in docs/schema, but not the deployment descriptor schemas and DTDs.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 12:30:23 2011
From: jira-events at lists.jboss.org (Gerry Matte (JIRA))
Date: Tue, 12 Jul 2011 12:30:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1263) Publish deployment
 descriptor schemas and dtd in the dist
In-Reply-To: <2078190816.48861.1310486183622.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <406849311.48907.1310488223658.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Gerry Matte commented on AS7-1263:
----------------------------------

Also, please publish the URLs for online versions of the schemas and dtds so that those who use xml editors can insert the schema URI into their files for validation purposes.

> Publish deployment descriptor schemas and dtd in the dist
> ---------------------------------------------------------
>
>                 Key: AS7-1263
>                 URL: https://issues.jboss.org/browse/AS7-1263
>             Project: Application Server 7
>          Issue Type: Task
>    Affects Versions: 7.0.0.Final
>            Reporter: Brian Stansberry
>             Fix For: 7.0.1.Final
>
>
> AS 7.0 has the domain/host/standalone config schemas in docs/schema, but not the deployment descriptor schemas and DTDs.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 12:34:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 12 Jul 2011 12:34:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-712) Publish all
 org.jboss.domain.* schemas to http://www.jboss.org/schema/
In-Reply-To: <260965286.28241.1304436318263.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1416302715.48910.1310488463634.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-712:
---------------------------------

         Assignee: Brian Stansberry
    Fix Version/s: 7.0.1.Final
                       (was: 7.0.0.Final)


> Publish all org.jboss.domain.* schemas to http://www.jboss.org/schema/
> ----------------------------------------------------------------------
>
>                 Key: AS7-712
>                 URL: https://issues.jboss.org/browse/AS7-712
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Blocker
>             Fix For: 7.0.1.Final
>
>
> http://community.jboss.org/wiki/JBossDTDs

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 12:37:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 12 Jul 2011 12:37:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1263) Publish deployment
 descriptor schemas and dtd in the dist
In-Reply-To: <2078190816.48861.1310486183622.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <516538835.48914.1310488643641.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on AS7-1263:
---------------------------------------

That's in progress; see AS7-712. Temporarily the links shown on https://github.com/jbossas/jboss-as/tree/7.0.0.Final/build/src/main/resources/docs/schema can be used. Well, those links should be good permanently, but we'll get them in the official http://www.jboss.org/schema/jbossas listings.


> Publish deployment descriptor schemas and dtd in the dist
> ---------------------------------------------------------
>
>                 Key: AS7-1263
>                 URL: https://issues.jboss.org/browse/AS7-1263
>             Project: Application Server 7
>          Issue Type: Task
>    Affects Versions: 7.0.0.Final
>            Reporter: Brian Stansberry
>             Fix For: 7.0.1.Final
>
>
> AS 7.0 has the domain/host/standalone config schemas in docs/schema, but not the deployment descriptor schemas and DTDs.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 12:39:23 2011
From: jira-events at lists.jboss.org (Gerry Matte (JIRA))
Date: Tue, 12 Jul 2011 12:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1264) Add schema references
 to standalone.xml, domain.xml, host.xml
Message-ID: <1620974387.48924.1310488763828.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Add schema references to standalone.xml, domain.xml, host.xml
-------------------------------------------------------------

                 Key: AS7-1264
                 URL: https://issues.jboss.org/browse/AS7-1264
             Project: Application Server 7
          Issue Type: Task
          Components: Domain Management
    Affects Versions: 7.0.0.CR1
            Reporter: Gerry Matte
            Assignee: Brian Stansberry


It appears that users of Jboss 7 will be often modifying these configuration files as they fine tune their server and when they discover how to implement new features.

It seems quite surprising to me that these files do not have the schema references identified in the file header.  Any good XML editor would use those references to validate changes and new entries and thereby avoid a great deal of frustration for users and those who provide support for forum issues.

I realise that if jboss validated each xml file when starting up there would be performance penalty that may be unacceptable to many users.  A command-line switch could be used to either turn on xml validation (if the default were that no validation is performed) or conversely to turn off xml validation if the default state was that xml validation was on.

Personally I favor having a switch that turns off validation - to be used on production servers only.

If the schema/dtd files were published online and referenced within the configuration xml files, future changes to the schema structure would be "enforced" upon the user community as they attemted to use an out-of-date version when upgrading to a new version of Jboss 7. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 12:43:23 2011
From: jira-events at lists.jboss.org (Gerry Matte (JIRA))
Date: Tue, 12 Jul 2011 12:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1264) Add schema references
 to standalone.xml, domain.xml, host.xml
In-Reply-To: <1620974387.48924.1310488763828.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1682175460.48930.1310489003649.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Gerry Matte updated AS7-1264:
-----------------------------

        Description: 
It appears that users of Jboss 7 will be often modifying these configuration files as they fine tune their server and when they discover how to implement new features.

It seems quite surprising to me that these files do not have the schema references identified in the file header.  Any good XML editor would use those references to validate changes and new entries and thereby avoid a great deal of frustration for users and those who provide support for forum issues.

I realise that if jboss validated each xml file when starting up there would be performance penalty that may be unacceptable to many users.  A command-line switch could be used to either turn on xml validation (if the default were that no validation is performed) or conversely to turn off xml validation if the default state was that xml validation was on.

Personally I favor having a switch that turns off validation - to be used on production servers only.

If the schema/dtd files were published online and referenced within the configuration xml files, future changes to the schema structure would be "enforced" upon the user community as they attempted to use an out-of-date version when upgrading to a new version of Jboss 7. 

  was:
It appears that users of Jboss 7 will be often modifying these configuration files as they fine tune their server and when they discover how to implement new features.

It seems quite surprising to me that these files do not have the schema references identified in the file header.  Any good XML editor would use those references to validate changes and new entries and thereby avoid a great deal of frustration for users and those who provide support for forum issues.

I realise that if jboss validated each xml file when starting up there would be performance penalty that may be unacceptable to many users.  A command-line switch could be used to either turn on xml validation (if the default were that no validation is performed) or conversely to turn off xml validation if the default state was that xml validation was on.

Personally I favor having a switch that turns off validation - to be used on production servers only.

If the schema/dtd files were published online and referenced within the configuration xml files, future changes to the schema structure would be "enforced" upon the user community as they attemted to use an out-of-date version when upgrading to a new version of Jboss 7. 

    Forum Reference: http://community.jboss.org/thread/169301


> Add schema references to standalone.xml, domain.xml, host.xml
> -------------------------------------------------------------
>
>                 Key: AS7-1264
>                 URL: https://issues.jboss.org/browse/AS7-1264
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>    Affects Versions: 7.0.0.CR1
>            Reporter: Gerry Matte
>            Assignee: Brian Stansberry
>              Labels: domain, host, standalone, xml, xmlns
>
> It appears that users of Jboss 7 will be often modifying these configuration files as they fine tune their server and when they discover how to implement new features.
> It seems quite surprising to me that these files do not have the schema references identified in the file header.  Any good XML editor would use those references to validate changes and new entries and thereby avoid a great deal of frustration for users and those who provide support for forum issues.
> I realise that if jboss validated each xml file when starting up there would be performance penalty that may be unacceptable to many users.  A command-line switch could be used to either turn on xml validation (if the default were that no validation is performed) or conversely to turn off xml validation if the default state was that xml validation was on.
> Personally I favor having a switch that turns off validation - to be used on production servers only.
> If the schema/dtd files were published online and referenced within the configuration xml files, future changes to the schema structure would be "enforced" upon the user community as they attempted to use an out-of-date version when upgrading to a new version of Jboss 7. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 12:49:23 2011
From: jira-events at lists.jboss.org (Gerry Matte (JIRA))
Date: Tue, 12 Jul 2011 12:49:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1263) Publish deployment
 descriptor schemas and dtd in the dist
In-Reply-To: <2078190816.48861.1310486183622.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <795097193.48943.1310489363643.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Gerry Matte commented on AS7-1263:
----------------------------------

Thanks Brian.

> Publish deployment descriptor schemas and dtd in the dist
> ---------------------------------------------------------
>
>                 Key: AS7-1263
>                 URL: https://issues.jboss.org/browse/AS7-1263
>             Project: Application Server 7
>          Issue Type: Task
>    Affects Versions: 7.0.0.Final
>            Reporter: Brian Stansberry
>             Fix For: 7.0.1.Final
>
>
> AS 7.0 has the domain/host/standalone config schemas in docs/schema, but not the deployment descriptor schemas and DTDs.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 13:28:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 12 Jul 2011 13:28:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1265) Infinispan cache
 containers registered using DefaultDomain JMX domain
Message-ID: <92237816.49014.1310491703613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Infinispan cache containers registered using DefaultDomain JMX domain
---------------------------------------------------------------------

                 Key: AS7-1265
                 URL: https://issues.jboss.org/browse/AS7-1265
             Project: Application Server 7
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 7.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
            Priority: Minor
             Fix For: 7.0.1.Final


Fix the jmx domain used to register infinispan cache managers to match the convention used by other AS components.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 13:31:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 12 Jul 2011 13:31:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1266) Infinispan caches
 should have jmx statistics enabled
Message-ID: <163586529.49017.1310491883658.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Infinispan caches should have jmx statistics enabled
----------------------------------------------------

                 Key: AS7-1266
                 URL: https://issues.jboss.org/browse/AS7-1266
             Project: Application Server 7
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 7.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 7.0.1.Final


Infinispan cache managers have global jmx statistics enabled, but not individual caches.  Update EmbeddedCacheManagerService to enable this on the default cache if an mbean server is present.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 15:18:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 12 Jul 2011 15:18:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1260) JGroups subsystem
 fails to setup some protocol stacks.
In-Reply-To: <1568744513.48245.1310478143759.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1640891136.49201.1310498303866.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro commented on AS7-1260:
-----------------------------------

Yup.  Sloppy job on my part.  Fix on the way.

> JGroups subsystem fails to setup some protocol stacks.
> ------------------------------------------------------
>
>                 Key: AS7-1260
>                 URL: https://issues.jboss.org/browse/AS7-1260
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.Final
>            Reporter: Trustin Lee
>            Assignee: Paul Ferraro
>            Priority: Critical
>
> After upgrading from AS 7.0.0.CR1 to AS 7.0.0.Final, I started to see an exception raised by org.jboss.as.clustering.jgroups.JChannelFactory:
> {code}
> 22:11:54,040 ERROR [stderr] (MSC service thread 1-1) java.lang.IllegalArgumentException: org.jgroups.ChannelException: unable to setup the protocol stack
> 22:11:54,040 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.ChannelProvider.getJGroupsChannel(ChannelProvider.java:71)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:273)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:226)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:254)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:148)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at java.lang.reflect.Method.invoke(Method.java:597)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:918)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:711)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:611)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:176)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:171)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.CacheImpl.start(CacheImpl.java:366)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:559)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:479)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:84)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:73)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:73)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at java.lang.Thread.run(Thread.java:680)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) Caused by: org.jgroups.ChannelException: unable to setup the protocol stack
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.init(JChannel.java:1728)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.<init>(JChannel.java:249)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.jgroups.JChannelFactory$JChannel.<init>(JChannelFactory.java:269)
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:69)
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.ChannelProvider.getJGroupsChannel(ChannelProvider.java:67)
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	... 26 more
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) Caused by: java.lang.IllegalArgumentException: the following properties in PING are not recognized: {bind_addr=192.168.0.196}
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.createLayer(Configurator.java:460)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.createProtocols(Configurator.java:393)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:88)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:55)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:534)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.init(JChannel.java:1725)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	... 30 more
> {code}
> (Actually, the exception was being swallowed by Infinispan, so I had to modify the source code in Infinispan.)
> Reverting back only the JGroups subsystem to 7.0.0.CR1 fixes the problem for UDP stack.  TCP stack still fails when configuring MPING:
> {code}
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) Caused by: java.lang.IllegalArgumentException: the following properties in MPING are not recognized: {start_port=0}
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.createLayer(Configurator.java:460)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.createProtocols(Configurator.java:393)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:88)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:55)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:534)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.JChannel.init(JChannel.java:1725)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	... 30 more
> {code}
> The offending subsystem configuration is:
> {code}
>         <subsystem xmlns="urn:jboss:domain:jgroups:1.0" default-stack="udp">
>             <stack name="udp">
>                 <transport type="UDP"
>                            socket-binding="jgroups-udp"
>                            default-executor="jgroups"
>                            oob-executor="jgroups-oob"
>                            timer-executor="jgroups-timer"/>
>                 <protocol type="PING"/>
>                 <protocol type="MERGE2"/>
>                 <protocol type="FD_SOCK"/>
>                 <protocol type="FD"/>
>                 <protocol type="VERIFY_SUSPECT"/>
>                 <protocol type="BARRIER"/>
>                 <protocol type="pbcast.NAKACK"/>
>                 <protocol type="UNICAST"/>
>                 <protocol type="pbcast.STABLE"/>
>                 <protocol type="VIEW_SYNC"/>
>                 <protocol type="pbcast.GMS"/>
>                 <protocol type="UFC"/>
>                 <protocol type="MFC"/>
>                 <protocol type="FRAG2"/>
>                 <protocol type="pbcast.STREAMING_STATE_TRANSFER"/>
>                 <protocol type="pbcast.FLUSH"/>
>             </stack>
>             <stack name="tcp">
>                 <transport type="TCP"
>                            socket-binding="jgroups-tcp"
>                            default-executor="jgroups"
>                            oob-executor="jgroups-oob"
>                            timer-executor="jgroups-timer"/>
>                 <protocol type="MPING" socket-binding="jgroups-mping"/>
>                 <protocol type="MERGE2"/>
>                 <protocol type="FD_SOCK"/>
>                 <protocol type="FD"/>
>                 <protocol type="VERIFY_SUSPECT"/>
>                 <protocol type="BARRIER"/>
>                 <protocol type="pbcast.NAKACK"/>
>                 <protocol type="UNICAST"/>
>                 <protocol type="pbcast.STABLE"/>
>                 <protocol type="VIEW_SYNC"/>
>                 <protocol type="pbcast.GMS"/>
>                 <protocol type="UFC"/>
>                 <protocol type="MFC"/>
>                 <protocol type="FRAG2"/>
>                 <protocol type="pbcast.STREAMING_STATE_TRANSFER"/>
>                 <protocol type="pbcast.FLUSH"/>
>             </stack>
>         </subsystem>
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 15:30:23 2011
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 12 Jul 2011 15:30:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-967) Upgrade Hibernate
 Validator to 4.2.0.Final
In-Reply-To: <187933026.11620.1307532239377.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <88850820.49208.1310499023774.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Shelly McGowan commented on AS7-967:
------------------------------------

https://github.com/smcgowan/jboss-as/commit/2489e6f3bccb7170d50cfe60f5905fda9a53bd44

> Upgrade Hibernate Validator to 4.2.0.Final
> ------------------------------------------
>
>                 Key: AS7-967
>                 URL: https://issues.jboss.org/browse/AS7-967
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Modules
>    Affects Versions: 7.0.0.Beta3
>            Reporter: Juergen Zimmermann
>            Assignee: Shelly McGowan
>             Fix For: 7.1.0.Alpha1
>
>
> HV 4.2 provides the pretty effective method failFast().

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 15:32:23 2011
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Tue, 12 Jul 2011 15:32:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-967) Upgrade Hibernate
 Validator to 4.2.0.Final
In-Reply-To: <187933026.11620.1307532239377.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <404375236.49212.1310499143672.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Shelly McGowan commented on AS7-967:
------------------------------------

Pull Request Submitted:
http://lists.jboss.org/pipermail/jbossas-pull-requests/2011-July/001113.html

> Upgrade Hibernate Validator to 4.2.0.Final
> ------------------------------------------
>
>                 Key: AS7-967
>                 URL: https://issues.jboss.org/browse/AS7-967
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Modules
>    Affects Versions: 7.0.0.Beta3
>            Reporter: Juergen Zimmermann
>            Assignee: Shelly McGowan
>             Fix For: 7.1.0.Alpha1
>
>
> HV 4.2 provides the pretty effective method failFast().

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 15:41:23 2011
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 12 Jul 2011 15:41:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1267) Can't set "append"
 attribute on file handlers
Message-ID: <1022396644.49217.1310499683625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Can't set "append" attribute on file handlers
---------------------------------------------

                 Key: AS7-1267
                 URL: https://issues.jboss.org/browse/AS7-1267
             Project: Application Server 7
          Issue Type: Bug
          Components: Logging
    Affects Versions: 7.1.0.Alpha1
            Reporter: Stan Silvert
            Assignee: David Lloyd


I can't tell what is really happening here.  It seems to parse the "append" attribute OK, but it doesn't show up in the CLI.  I've also set it programmatically in the console code, but I never get a value back for it.

           <periodic-rotating-file-handler name="FILE">
                <level name="INFO"/>
                <formatter>
                    <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
                </formatter>
                <file relative-to="jboss.server.log.dir" path="server.log"/>
                <suffix value=".yyyy-MM-dd"/>
                <append value="true"/>
            </periodic-rotating-file-handler>


[standalone at localhost:9999 /] /subsystem=logging/periodic-rotating-file-handler=FILE:read-resource
{
    "outcome" => "success",
    "result" => {
        "autoflush" => true,
        "encoding" => undefined,
        "file" => {
            "path" => "server.log",
            "relative-to" => "jboss.server.log.dir"
        },
        "formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n",
        "level" => "INFO",
        "suffix" => ".yyyy-MM-dd"
    }
}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 15:43:23 2011
From: jira-events at lists.jboss.org (Brad Davis (JIRA))
Date: Tue, 12 Jul 2011 15:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3110) Amazon S3
	Drools Resource
In-Reply-To: <134044432.28433.1309372524057.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <457096589.49222.1310499803675.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brad Davis commented on JBRULES-3110:
-------------------------------------

I am uploading a new copy of the S3 Integration.  It ensures only the meta-information is pulled when checking timestamps to make the process more efficient.

> Amazon S3 Drools Resource
> -------------------------
>
>                 Key: JBRULES-3110
>                 URL: https://issues.jboss.org/browse/JBRULES-3110
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.1.1.FINAL
>            Reporter: Brad Davis
>            Assignee: Mark Proctor
>         Attachments: drools-io-s3.zip
>
>
> Attached is a Drools Resource for pulling down rules and polling with the knowledge agent against Amazon S3.  To run the unit tests, make sure to set a correct AWS access key and secret key in the base test case!
> This request for this component from a client who is currently already building in the Amazon cloud, and wanted to ensure that Drools was pulling from a replicated, hightly available datastore.
> It uses JetS3t for the communication to S3.  I imagine this could be a separate component in itself, since there i no need to introduce the jets3t dependency into the Drools Core.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 15:45:23 2011
From: jira-events at lists.jboss.org (Brad Davis (JIRA))
Date: Tue, 12 Jul 2011 15:45:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-3110) Amazon S3 Drools
	Resource
In-Reply-To: <134044432.28433.1309372524057.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <857889876.49226.1310499923988.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brad Davis updated JBRULES-3110:
--------------------------------

    Attachment: drools-io-s3.zip


Updated copy of the Drools S3 Integration.

> Amazon S3 Drools Resource
> -------------------------
>
>                 Key: JBRULES-3110
>                 URL: https://issues.jboss.org/browse/JBRULES-3110
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.1.1.FINAL
>            Reporter: Brad Davis
>            Assignee: Mark Proctor
>         Attachments: drools-io-s3.zip, drools-io-s3.zip
>
>
> Attached is a Drools Resource for pulling down rules and polling with the knowledge agent against Amazon S3.  To run the unit tests, make sure to set a correct AWS access key and secret key in the base test case!
> This request for this component from a client who is currently already building in the Amazon cloud, and wanted to ensure that Drools was pulling from a replicated, hightly available datastore.
> It uses JetS3t for the communication to S3.  I imagine this could be a separate component in itself, since there i no need to introduce the jets3t dependency into the Drools Core.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 16:43:23 2011
From: jira-events at lists.jboss.org (Alessandro Lazarotti (JIRA))
Date: Tue, 12 Jul 2011 16:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3135) Drools: Unable to
 load session snapshot
Message-ID: <1181896583.49309.1310503403626.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Drools: Unable to load session snapshot
---------------------------------------

                 Key: JBRULES-3135
                 URL: https://issues.jboss.org/browse/JBRULES-3135
             Project: Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
         Environment: Windows Server, SQL Server 2005, Tomcat 5.5, Hibernate, Bitronix
            Reporter: Alessandro Lazarotti
            Assignee: Edson Tirelli
            Priority: Blocker
             Fix For: 5.3.0.Beta1
         Attachments: TestCase.java, VoteCreatedEvent.java

After an event is processed the session fails to load using JPA persistence.

I ve attached a test case.
It uses a Drools flow file, and a drl file. Both very simple..
The flow file has a "Start" then an action that prints a message to the console, then "End"

The Drl has one rule that processes an event:

import com.kgcontrols.services.company.standardsRequests.workflow.events.VoteCreatedEvent

declare VoteCreatedEvent
       @role(event)
end

rule "testEvents"
       when
               VoteCreatedEvent() from entry-point "VoteCreatedStream"

       then
               System.out.println("--------------------------- YEAH the event got here");
end

I can see the "YEAH the event go here" on the console so I know the rule fired. But after that, if I try to load the session from the database I get:

                                                                       
                                                                     
                                                                     
                                             
--------------------------- YEAH the event got here
ERROR 2010-09-02 10:09:26 Servlet.service() for servlet jsp threw exception
java.lang.IllegalStateException: java.lang.reflect.InvocationTargetException
        at org.drools.persistence.jpa.impl.KnowledgeStoreServiceImpl.buildComman
Service(KnowledgeStoreServiceImpl.java:106)
        at org.drools.persistence.jpa.impl.KnowledgeStoreServiceImpl.loadStatefu
lKnowledgeSession(KnowledgeStoreServiceImpl.java:74)
        at org.drools.persistence.jpa.JPAKnowledgeService.loadStatefulKnowledgeS
ession(JPAKnowledgeService.java:118)
        at com.kgcontrols.services.company.standardsRequests.workflow.TestCase.
loadSession(TestCase.java:136)
        at com.kgcontrols.services.company.standardsRequests.workflow.TestCase.
start(TestCase.java:64)
        at org.apache.jsp.company.standardsRequest.test2_jsp._jspService(org.ap
ache.jsp.company.standardsRequest.test2_jsp:51)
        at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
        at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper
.java:332)
        at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:3
14)
        at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:252)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:173)
        at com.troux.servercommon.usagelog.UsageLogFilter.doFilter(UsageLogFilte
r.java:149)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:202)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:173)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:213)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:178)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica
torBase.java:524)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:126)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:105)
        at org.apache.catalina.valves.FastCommonAccessLogValve.invoke(FastCommon
AccessLogValve.java:495)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:107)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
a:148)
        at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:199)

        at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:282)
        at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:754)
        at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.ja
va:684)
        at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSock
et.java:876)
        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP
ool.java:684)
        at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct
orAccessorImpl.java:39)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC
onstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
        at org.drools.persistence.jpa.impl.KnowledgeStoreServiceImpl.buildComman
Service(KnowledgeStoreServiceImpl.java:91)
        ... 31 more
Caused by: java.lang.RuntimeException: Unable to load session snapshot
        at org.drools.persistence.session.JPASessionMarshallingHelper.loadSnapsh
ot(JPASessionMarshallingHelper.java:96)
        at org.drools.persistence.session.SingleSessionCommandService.initKsessi
on(SingleSessionCommandService.java:196)
        at org.drools.persistence.session.SingleSessionCommandService.<init>(Sin
gleSessionCommandService.java:159)
        ... 36 more
Caused by: java.lang.NullPointerException
        at org.drools.reteoo.LeftTuple.<init>(LeftTuple.java:135)
        at org.drools.reteoo.LeftTuple.<init>(LeftTuple.java:121)
        at org.drools.marshalling.impl.InputMarshaller.readLeftTuple(InputMarsha
ller.java:461)
        at org.drools.marshalling.impl.InputMarshaller.readFactHandles(InputMars
haller.java:351)
        at org.drools.marshalling.impl.InputMarshaller.readSession(InputMarshall
er.java:205)
        at org.drools.marshalling.impl.DefaultMarshaller.unmarshall(DefaultMarsh
aller.java:91)
        at org.drools.persistence.session.JPASessionMarshallingHelper.loadSnapsh
ot(JPASessionMarshallingHelper.java:91)
        ... 38 more
ERROR 2010-09-02 10:09:26 [EXCEPTION]
org.apache.jasper.JasperException: java.lang.reflect.InvocationTargetException
        at org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspSer
vletWrapper.java:510)
        at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper
.java:387)
        at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:3
14)
        at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:252)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:173)
        at com.troux.servercommon.usagelog.UsageLogFilter.doFilter(UsageLogFilte
r.java:149)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:202)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:173)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:213)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:178)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica
torBase.java:524)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:126)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:105)
        at org.apache.catalina.valves.FastCommonAccessLogValve.invoke(FastCommon
AccessLogValve.java:495)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:107)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
a:148)
        at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:199)

        at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:282)
        at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:754)
        at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.ja
va:684)
        at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSock
et.java:876)
        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP
ool.java:684)
        at java.lang.Thread.run(Thread.java:619)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 17:13:23 2011
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 12 Jul 2011 17:13:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1268) Can't update
 subhandler on async handler
Message-ID: <809971781.49345.1310505203625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Can't update subhandler on async handler
----------------------------------------

                 Key: AS7-1268
                 URL: https://issues.jboss.org/browse/AS7-1268
             Project: Application Server 7
          Issue Type: Bug
          Components: Logging
    Affects Versions: 7.1.0.Alpha1
            Reporter: Stan Silvert
            Assignee: David Lloyd


David, sorry if I'm assigning to the wrong person.  I guess this could be a CLI bug.

[standalone at localhost:9999 /] cd subsystem=logging/async-handler=ASYNC
[standalone at localhost:9999 async-handler=ASYNC] :read-resource(recursive=true)
{
    "outcome" => "success",
    "result" => {
        "level" => "INFO",
        "overflow-action" => "BLOCK",
        "queue-length" => 1024,
        "subhandlers" => ["FILE"]
    }
}
[standalone at localhost:9999 async-handler=ASYNC] :update-properties(subhandlers=["CONSOLE"])
{"outcome" => "success"}
[standalone at localhost:9999 async-handler=ASYNC] :read-resource(recursive=true)
{
    "outcome" => "success",
    "result" => {
        "level" => "INFO",
        "overflow-action" => "BLOCK",
        "queue-length" => 1024,
        "subhandlers" => ["FILE"]
    }
}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 19:22:23 2011
From: jira-events at lists.jboss.org (stevearoonie (JIRA))
Date: Tue, 12 Jul 2011 19:22:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2930)
 KnowledgeAgentDefinitionParser can get NPEs
In-Reply-To: <266504217.41099.1300754985643.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1346441401.49436.1310512943739.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

stevearoonie commented on JBRULES-2930:
---------------------------------------

Until this is fixed the workaround is to redundantly specify the bean class in the child bean definitions. Note this is all bean definitions, not just Drools related ones.

> KnowledgeAgentDefinitionParser can get NPEs
> -------------------------------------------
>
>                 Key: JBRULES-2930
>                 URL: https://issues.jboss.org/browse/JBRULES-2930
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-spring
>    Affects Versions: 5.1.1.FINAL
>            Reporter: stevearoonie
>            Assignee: Mauricio Salatino
>             Fix For: 5.3.0.Beta1
>
>
> KnowledgeAgentDefinitionParser assumes that a spring bean definition has a bean class name, however when the bean extends a parent then it may not, as in the following example:
> 	<bean id="freemarkerConfiguration"  class="freemarker.template.Configuration">        
>         </bean>
> 	
> 	<bean id="workflowFreemarkerConfiguration" parent="freemarkerConfiguration">
> 		<property name="templateLoader">
> 			<bean class="au.com.core.messaging.freemarker.FreemarkerMessageLayoutTemplateLoader" />
> 		</property>
> 	</bean>
> The BeanDefinition for bean "workflowFreemarkerConfiguration" has a null bean class name which causes KnowledgeAgentDefinitionParser.parseInternal to throw an NPE. Specifically this line:
> if ( def.getBeanClassName().equals( StatelessKnowledgeSessionBeanFactory.class.getName() ) ) {

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 19:24:23 2011
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Tue, 12 Jul 2011 19:24:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3136) Exception when
 extending non-bean classes
Message-ID: <1029911192.49440.1310513063624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Exception when extending non-bean classes
-----------------------------------------

                 Key: JBRULES-3136
                 URL: https://issues.jboss.org/browse/JBRULES-3136
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.2.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor
             Fix For: 5.3.0.Beta1


When a declared class extends another, the compiler looks for fields in the superclass using the getter methods, which are then reused by the internal field readers/writers. When a superclass has a field with a getter only (i.e. no setter), an exception is thrown.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 19:36:23 2011
From: jira-events at lists.jboss.org (Alessandro Lazarotti (JIRA))
Date: Tue, 12 Jul 2011 19:36:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3137)
 NullPointerException in FromNode.destroyCreatedHandles
Message-ID: <658399493.49463.1310513783730.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

NullPointerException in FromNode.destroyCreatedHandles
------------------------------------------------------

                 Key: JBRULES-3137
                 URL: https://issues.jboss.org/browse/JBRULES-3137
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
            Reporter: Alessandro Lazarotti
            Assignee: Mark Proctor
             Fix For: 5.2.0.CR1


I received this NullPointerException after upgrading to drools 5.1.1.  The NullPointerException is being thrown when the rule executes "update($build);" where $build is set in the LHS from a Build in working memory.  I'm not sure if the bug is that matches may be null and a null check needs to be added or if something else is going on causing the tuple to not be found.

Caused by: java.lang.NullPointerException
	at org.drools.reteoo.FromNode.destroyCreatedHandles(FromNode.java:336)
	at org.drools.reteoo.FromNode.retractLeftTuple(FromNode.java:326)
	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateRetractLeftTuple(CompositeLeftTupleSinkAdapter.java:238)
	at org.drools.reteoo.CompositeLeftTupleSinkAdapter.propagateRetractRightTuple(CompositeLeftTupleSinkAdapter.java:155)
	at org.drools.reteoo.JoinNode.retractRightTuple(JoinNode.java:151)
	at org.drools.reteoo.ModifyPreviousTuples.retractTuples(ModifyPreviousTuples.java:126)
	at org.drools.reteoo.EntryPointNode.modifyObject(EntryPointNode.java:176)
	at org.drools.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:1442)
	at org.drools.common.AbstractWorkingMemory.update(AbstractWorkingMemory.java:1349)
	at org.drools.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:183)
	at org.drools.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:196)
	at buildSchedulerV2.Rule_Combine_Builds_0.defaultConsequence(Rule_Combine_Builds_0.java:36)
	at buildSchedulerV2.Rule_Combine_Builds_0DefaultConsequenceInvoker.evaluate(Rule_Combine_Builds_0DefaultConsequenceInvoker.java:49)
	at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:917)


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 20:49:23 2011
From: jira-events at lists.jboss.org (Cristiano Nicolai (JIRA))
Date: Tue, 12 Jul 2011 20:49:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3138)
 NullPointerException on RuleFlowGroupImpl after a rollback on a
 StatefulKnowledgeSession
Message-ID: <407506615.49638.1310518163610.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

NullPointerException on RuleFlowGroupImpl after a rollback on a StatefulKnowledgeSession
----------------------------------------------------------------------------------------

                 Key: JBRULES-3138
                 URL: https://issues.jboss.org/browse/JBRULES-3138
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.2.0.Final
            Reporter: Cristiano Nicolai
            Assignee: Mark Proctor


After executing some action that causes the StatefulKnowledgeSession to rollback, a NullPointerExption is throw on RuleFlowGroupImpl.setActive(RuleFlowGroupImpl.java:121) when it tries to use the workingMemory object. It seems that RuleFlowGroupImpl is not correctly deserialized/recreated after the rollback.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 20:51:23 2011
From: jira-events at lists.jboss.org (Cristiano Nicolai (JIRA))
Date: Tue, 12 Jul 2011 20:51:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-3138)
 NullPointerException on RuleFlowGroupImpl after a rollback on a
 StatefulKnowledgeSession
In-Reply-To: <407506615.49638.1310518163610.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1968783831.49643.1310518283646.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Cristiano Nicolai updated JBRULES-3138:
---------------------------------------

    Attachment: process-test.zip


Test to reproduce the described behavior.

> NullPointerException on RuleFlowGroupImpl after a rollback on a StatefulKnowledgeSession
> ----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3138
>                 URL: https://issues.jboss.org/browse/JBRULES-3138
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.2.0.Final
>            Reporter: Cristiano Nicolai
>            Assignee: Mark Proctor
>         Attachments: process-test.zip
>
>
> After executing some action that causes the StatefulKnowledgeSession to rollback, a NullPointerExption is throw on RuleFlowGroupImpl.setActive(RuleFlowGroupImpl.java:121) when it tries to use the workingMemory object. It seems that RuleFlowGroupImpl is not correctly deserialized/recreated after the rollback.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 21:35:23 2011
From: jira-events at lists.jboss.org (John Ament (JIRA))
Date: Tue, 12 Jul 2011 21:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1269) Injection via @EJB
	fails
Message-ID: <1010288523.49667.1310520923613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Injection via @EJB fails
------------------------

                 Key: AS7-1269
                 URL: https://issues.jboss.org/browse/AS7-1269
             Project: Application Server 7
          Issue Type: Bug
            Reporter: John Ament


https://gist.github.com/1079559

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 22:04:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 12 Jul 2011 22:04:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1270) Get the right order
 of child types in the read-children-types op
Message-ID: <965024903.49670.1310522663614.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Get the right order of child types in the read-children-types op
----------------------------------------------------------------

                 Key: AS7-1270
                 URL: https://issues.jboss.org/browse/AS7-1270
             Project: Application Server 7
          Issue Type: Task
          Components: Domain Management
    Affects Versions: 7.0.0.Final
            Reporter: Brian Stansberry
            Priority: Minor
             Fix For: 7.1.0.Beta2


Seem like the children types are in random order:

[domain at localhost:9999 /] :read-children-types
{
    "outcome" => "success",
    "result" => [
        "extension",
        "host",
        "server-group",
        "path",
        "system-property",
        "deployment",
        "interface",
        "socket-binding-group",
        "profile"
    ]
}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 12 22:10:23 2011
From: jira-events at lists.jboss.org (John Ament (JIRA))
Date: Tue, 12 Jul 2011 22:10:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1271) Fired object messages
 violate classloaders
Message-ID: <886860909.49673.1310523023634.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Fired object messages violate classloaders
------------------------------------------

                 Key: AS7-1271
                 URL: https://issues.jboss.org/browse/AS7-1271
             Project: Application Server 7
          Issue Type: Bug
            Reporter: John Ament


JMS allows you to fire an object message.  In this case, I have a object of type in my deployment.  It fires fine.  I bind a message consumer to a queue in AS7.  the object message coming in results in a classloader violation:

22:13:35,116 ERROR [org.jboss.seam.jms.example.statuswatcher.messagedriven.DistributorMDB] (Thread-2 (group:HornetQ-client-global-threads-767046602)) org.jboss.seam.jms.example.statuswatcher.model.Status from [Module "org.hornetq:main" from local module loader @19d009b4 (roots: /apps/jboss-as-7.0.0.Final/modules)]: javax.jms.JMSException: org.jboss.seam.jms.example.statuswatcher.model.Status from [Module "org.hornetq:main" from local module loader @19d009b4 (roots: /apps/jboss-as-7.0.0.Final/modules)]
	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
	at java.lang.Class.forName0(Native Method) [:1.6.0_22]
	at java.lang.Class.forName(Class.java:247) [:1.6.0_22]
	at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:603) [:1.6.0_22]
	at org.hornetq.utils.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:69) [hornetq-core-2.2.6.Final.jar:]
	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1574) [:1.6.0_22]
	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495) [:1.6.0_22]
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731) [:1.6.0_22]
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) [:1.6.0_22]
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) [:1.6.0_22]
	at org.hornetq.jms.client.HornetQObjectMessage.getObject(HornetQObjectMessage.java:158) [hornetq-jms-2.2.6.Final.jar:]
	at org.jboss.seam.jms.example.statuswatcher.messagedriven.DistributorMDB.onMessage(DistributorMDB.java:46)
	at org.hornetq.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:91) [hornetq-jms-2.2.6.Final.jar:]
	at org.hornetq.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:866) [hornetq-core-2.2.6.Final.jar:]
	at org.hornetq.core.client.impl.ClientConsumerImpl.access$100(ClientConsumerImpl.java:44) [hornetq-core-2.2.6.Final.jar:]
	at org.hornetq.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:983) [hornetq-core-2.2.6.Final.jar:]
	at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.6.Final.jar:]
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_22]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_22]
	at java.lang.Thread.run(Thread.java:662) [:1.6.0_22]


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 00:05:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 13 Jul 2011 00:05:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1224) Document the
 "management resource" notion in the Admin Guide
In-Reply-To: <356943798.40411.1310057843613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <464845950.49706.1310529923678.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry resolved AS7-1224.
-----------------------------------

    Resolution: Done


> Document the "management resource" notion in the Admin Guide
> ------------------------------------------------------------
>
>                 Key: AS7-1224
>                 URL: https://issues.jboss.org/browse/AS7-1224
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 7.0.0.Final
>
>
> In the "Core management concepts" section of the Admin Guide, add a section describing what a management resource is and outlining the basic resource tree server for both a standalone server and a managed domain.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 00:05:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 13 Jul 2011 00:05:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1223) Document the global
 operations in the Admin Guide
In-Reply-To: <1714268649.40407.1310057724010.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1465867460.49708.1310529923780.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry resolved AS7-1223.
-----------------------------------

    Resolution: Done


> Document the global operations in the Admin Guide
> -------------------------------------------------
>
>                 Key: AS7-1223
>                 URL: https://issues.jboss.org/browse/AS7-1223
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 7.0.0.Final
>
>
> Document the global operations.
> Should cover "add" and "remove" as well.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 00:26:23 2011
From: jira-events at lists.jboss.org (Trustin Lee (JIRA))
Date: Wed, 13 Jul 2011 00:26:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1272) Infinispan subsystem
 configures its transport with invalid timeout values.
Message-ID: <1505967125.49711.1310531183918.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Infinispan subsystem configures its transport with invalid timeout values.
--------------------------------------------------------------------------

                 Key: AS7-1272
                 URL: https://issues.jboss.org/browse/AS7-1272
             Project: Application Server 7
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 7.0.0.Final
            Reporter: Trustin Lee
            Assignee: Paul Ferraro


Whenever I start the Infinispan subsystem, I see the following warning:

{code}
13:20:23,854 WARN  [org.infinispan.config.TimeoutConfigurationValidatingVisitor] (MSC service thread 1-4) ISPN00148: Invalid <transport>: distributedSyncTimout value of 240000. It can not be higher than <stateRetrieval>:timeout which is 10000
{code}

The current subsystem configuration looks like the following:

{code}
        <subsystem xmlns="urn:jboss:domain:infinispan:1.0" default-cache-container="default">
            <cache-container name="default"
                             default-cache="default"
                             listener-executor="infinispan-listener"
                             eviction-executor="infinispan-eviction"
                             replication-queue-executor="infinispan-repl-queue">
                <transport executor="infinispan-transport"
                           lock-timeout="240000"/>
                <distributed-cache name="default"
                                   start="EAGER"
                                   mode="SYNC"
                                   virtual-nodes="1" 
                                   owners="2" 
                                   batching="false" 
                                   indexing="NONE" 
                                   l1-lifespan="0" 
                                   remote-timeout="30000">
                    <locking isolation="REPEATABLE_READ" 
                             acquire-timeout="30000" 
                             concurrency-level="1000" 
                             striping="false" />
                    <rehashing enabled="true" 
                               timeout="600000" />
                </distributed-cache>
            </cache-container>
        </subsystem>
{code}

It seems like there are not all attribute that correspond to all transport timeout properties.  If that's intended, as least the subsystem should feed the sensible defaults to Infinispan.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 00:31:23 2011
From: jira-events at lists.jboss.org (Cristiano Nicolai (JIRA))
Date: Wed, 13 Jul 2011 00:31:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-3138)
 NullPointerException on RuleFlowGroupImpl after a rollback on a
 StatefulKnowledgeSession
In-Reply-To: <407506615.49638.1310518163610.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <857757180.49725.1310531483650.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Cristiano Nicolai updated JBRULES-3138:
---------------------------------------

    Git Pull Request: https://github.com/droolsjbpm/drools/pull/38


> NullPointerException on RuleFlowGroupImpl after a rollback on a StatefulKnowledgeSession
> ----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3138
>                 URL: https://issues.jboss.org/browse/JBRULES-3138
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.2.0.Final
>            Reporter: Cristiano Nicolai
>            Assignee: Mark Proctor
>         Attachments: process-test.zip
>
>
> After executing some action that causes the StatefulKnowledgeSession to rollback, a NullPointerExption is throw on RuleFlowGroupImpl.setActive(RuleFlowGroupImpl.java:121) when it tries to use the workingMemory object. It seems that RuleFlowGroupImpl is not correctly deserialized/recreated after the rollback.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 00:33:23 2011
From: jira-events at lists.jboss.org (Trustin Lee (JIRA))
Date: Wed, 13 Jul 2011 00:33:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-1252) Infinispan subsystem
 writer generates incorrect XML
In-Reply-To: <1889213554.45389.1310393843924.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1885895336.49730.1310531603844.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Trustin Lee closed AS7-1252.
----------------------------



Thanks a lot for a quick resolution!

> Infinispan subsystem writer generates incorrect XML
> ---------------------------------------------------
>
>                 Key: AS7-1252
>                 URL: https://issues.jboss.org/browse/AS7-1252
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.CR1
>            Reporter: Trustin Lee
>            Assignee: Brian Stansberry
>             Fix For: 7.0.0.Final
>
>
> The following XML configuration:
> {code}
>         <subsystem xmlns="urn:jboss:domain:infinispan:1.0" default-cache-container="default">
>             <cache-container name="default"
>                              default-cache="default"
>                              listener-executor="infinispan-listener"
>                              eviction-executor="infinispan-eviction"
>                              replication-queue-executor="infinispan-repl-queue">
>                 <transport executor="infinispan-transport"/>
>                 <distributed-cache name="default" start="EAGER" mode="SYNC" />
>             </cache-container>
>         </subsystem>
>         <subsystem xmlns="urn:jboss:domain:datagrid:endpoint:1.0">
>             ...
> {code}
> is written back to:
> {code}
>         <subsystem xmlns="urn:jboss:domain:infinispan:1.0" default-cache-container="default">
>             <cache-container name="default" default-cache="default" listener-executor="infinispan-listener" eviction-executor="infinispan-eviction" replication-queue-executor="infinispan-repl-queue">
>                 <transport executor="infinispan-transport">
>                     <distributed-cache mode="SYNC" name="default" start="EAGER"/>
>                 </transport>
>             </cache-container>
>             <subsystem xmlns="urn:jboss:domain:datagrid:endpoint:1.0">
>                 ...
> {code}
> making the subsequent startup fail.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 00:33:24 2011
From: jira-events at lists.jboss.org (Trustin Lee (JIRA))
Date: Wed, 13 Jul 2011 00:33:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-1251) Threads subsystem
 writer generates incorrect XML for unbounded queue thread pool
In-Reply-To: <735250516.45363.1310393483819.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <507149235.49735.1310531604054.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Trustin Lee closed AS7-1251.
----------------------------



Thanks a lot for a quick resolution!

> Threads subsystem writer generates incorrect XML for unbounded queue thread pool
> --------------------------------------------------------------------------------
>
>                 Key: AS7-1251
>                 URL: https://issues.jboss.org/browse/AS7-1251
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.CR1
>            Reporter: Trustin Lee
>            Assignee: Brian Stansberry
>             Fix For: 7.0.0.Final
>
>
> {code}
> <unbounded-queue-thread-pool name="jgroups">
> {code}
> is written back as:
> {code}
> <unbounded-queue-thread-pool blocking="jgroups">
> {code}
> Hence making the next startup fail.
> Similar issue was found and fixed (AS7-233).  We need to check all queue types.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 00:51:23 2011
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Wed, 13 Jul 2011 00:51:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1220) Add native management
 (ModelControllerClient) API docs to the Admin Guide
In-Reply-To: <1106331286.40360.1310056463696.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <152112332.49755.1310532683732.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jason Greene updated AS7-1220:
------------------------------

    Fix Version/s: 7.0.1.Final
                       (was: 7.0.0.Final)


> Add native management  (ModelControllerClient) API docs to the Admin Guide
> --------------------------------------------------------------------------
>
>                 Key: AS7-1220
>                 URL: https://issues.jboss.org/browse/AS7-1220
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 7.0.1.Final
>
>
> There's some brief docs on configuring the native management interface. There is a separate JIRA for some fundamental docs on jboss-dmr. There will be a page in the "Core management concepts" section on what management resources, attributes and operations are.
> This task is to reference those elements and bring together a coherent picture of how to use the ModelControllerClient API.
> A subtask would be to add docs on the helper classes in controller-client, although I'm fine with deferring that bit until later in the AS 7.1 cycle,

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 00:51:23 2011
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Wed, 13 Jul 2011 00:51:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1221) HTTP management API
 section in the Admin Guide
In-Reply-To: <603099484.40379.1310057124161.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2137299397.49758.1310532683797.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jason Greene updated AS7-1221:
------------------------------

    Fix Version/s: 7.0.1.Final
                       (was: 7.0.0.Final)


> HTTP management API section in the Admin Guide
> ----------------------------------------------
>
>                 Key: AS7-1221
>                 URL: https://issues.jboss.org/browse/AS7-1221
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 7.0.1.Final
>
>
> We need a technical guide to the HTTP management API.
> The "Management clients" section gives a basic overview. But it should reference a separate section that documents the usage of GET and POST, the URL patterns, the JSON representation of DMR etc.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 00:51:23 2011
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Wed, 13 Jul 2011 00:51:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1219) Add jboss-dmr
 documentation to the Admin Guide
In-Reply-To: <896759888.40346.1310056103706.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <492469432.49762.1310532683886.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jason Greene updated AS7-1219:
------------------------------

    Fix Version/s: 7.0.1.Final
                       (was: 7.0.0.Final)


> Add jboss-dmr documentation to the Admin Guide
> ----------------------------------------------
>
>                 Key: AS7-1219
>                 URL: https://issues.jboss.org/browse/AS7-1219
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 7.0.1.Final
>
>
> Basic documentation on DMR:
> 1) Purpose
> 2) Source location and maven coordinates
> 3) Description of the 2 public classes, ModelNode and ModelType, link to 1.0.0.Final code for each on github
> 4) Some simple examples
> 5) Fully document the string format, so people know how to read DMR output and how to write DMR input
> 6) Links to 5) above in the CLI docs, both in a place that describes how to read output and in a place that describes the format for parameter values in low-level operation requests 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 01:14:23 2011
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Wed, 13 Jul 2011 01:14:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3139) NPE in
 KnowledgeAgentImpl due to missing change set
Message-ID: <1006199521.49785.1310534063634.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

NPE in KnowledgeAgentImpl due to missing change set
---------------------------------------------------

                 Key: JBRULES-3139
                 URL: https://issues.jboss.org/browse/JBRULES-3139
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core  (expert)
            Reporter: Wolfgang Laun
            Assignee: Mark Proctor


A missing Change Set causes a NPE in KnowledgeAgentImpl.

import java.net.URL;
import org.drools.*;
import org.drools.agent.*;
import org.drools.conf.*;
import org.drools.builder.*;
import org.drools.io.*;

    public void setup() throws Exception {
	KnowledgeBaseConfiguration kBaseConfig =
	    KnowledgeBaseFactory.newKnowledgeBaseConfiguration();
        kBaseConfig.setOption(EventProcessingOption.STREAM);
	//   kBaseConfig.setOption( cehOption );

        ResourceChangeScannerConfiguration rcsConf =
            ResourceFactory.getResourceChangeScannerService()
                           .newResourceChangeScannerConfiguration();
        rcsConf.setProperty("drools.resource.scanner.interval", "20");
        ResourceFactory.getResourceChangeScannerService().configure( rcsConf );

        KnowledgeAgentConfiguration kaConf =
            KnowledgeAgentFactory.newKnowledgeAgentConfiguration();
        kaConf.setProperty("drools.agent.scanDirectories", "true");
        kaConf.setProperty("drools.agent.scanResources", "true");
        kaConf.setProperty("drools.agent.newInstance", "false");

        KnowledgeBase kBase =
            KnowledgeBaseFactory.newKnowledgeBase(kBaseConfig);
        KnowledgeAgent kAgent =
            KnowledgeAgentFactory.newKnowledgeAgent( "drools agent", kBase, kaConf);

        String urlString = "file://tmp/MissingChangeSet.xml";
        try {
             URL url = new URL(urlString);
             Resource urlResource = ResourceFactory.newUrlResource(url);

	     if( urlResource != null ){
		 System.out.println( "Resource " + urlResource );
	     }

             kAgent.applyChangeSet( urlResource );
        } catch (Exception e) {
             System.out.println("Caught exception: " + e.getMessage());
             e.printStackTrace();
        }
}


Caught exception: null
java.lang.NullPointerException
	at org.drools.agent.impl.KnowledgeAgentImpl.processChangeSet(KnowledgeAgentImpl.java:223)
	at org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:189)
	at org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:174)
	at hashcode.Main.setup(Main.java:75)


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 02:41:23 2011
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 13 Jul 2011 02:41:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-3138)
 NullPointerException on RuleFlowGroupImpl after a rollback on a
 StatefulKnowledgeSession
In-Reply-To: <407506615.49638.1310518163610.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <341913117.49853.1310539283726.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated JBRULES-3138:
---------------------------------------------

    Git Pull Request: https://github.com/droolsjbpm/drools/pull/38  (was: https://github.com/droolsjbpm/drools/pull/38)


> NullPointerException on RuleFlowGroupImpl after a rollback on a StatefulKnowledgeSession
> ----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3138
>                 URL: https://issues.jboss.org/browse/JBRULES-3138
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.2.0.Final
>            Reporter: Cristiano Nicolai
>            Assignee: Mark Proctor
>         Attachments: process-test.zip
>
>
> After executing some action that causes the StatefulKnowledgeSession to rollback, a NullPointerExption is throw on RuleFlowGroupImpl.setActive(RuleFlowGroupImpl.java:121) when it tries to use the workingMemory object. It seems that RuleFlowGroupImpl is not correctly deserialized/recreated after the rollback.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 02:41:23 2011
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 13 Jul 2011 02:41:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3138)
 NullPointerException on RuleFlowGroupImpl after a rollback on a
 StatefulKnowledgeSession
In-Reply-To: <407506615.49638.1310518163610.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <777842272.49857.1310539283815.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on JBRULES-3138:
--------------------------------------------------

Cristiano Nicolai <cnicolai at redhat.com> changed the Status of [bug 719783|https://bugzilla.redhat.com/show_bug.cgi?id=719783] from NEW to CLOSED

> NullPointerException on RuleFlowGroupImpl after a rollback on a StatefulKnowledgeSession
> ----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3138
>                 URL: https://issues.jboss.org/browse/JBRULES-3138
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.2.0.Final
>            Reporter: Cristiano Nicolai
>            Assignee: Mark Proctor
>         Attachments: process-test.zip
>
>
> After executing some action that causes the StatefulKnowledgeSession to rollback, a NullPointerExption is throw on RuleFlowGroupImpl.setActive(RuleFlowGroupImpl.java:121) when it tries to use the workingMemory object. It seems that RuleFlowGroupImpl is not correctly deserialized/recreated after the rollback.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 02:41:23 2011
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 13 Jul 2011 02:41:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3138)
 NullPointerException on RuleFlowGroupImpl after a rollback on a
 StatefulKnowledgeSession
In-Reply-To: <407506615.49638.1310518163610.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <536743601.49863.1310539283948.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on JBRULES-3138:
--------------------------------------------------

Cristiano Nicolai <cnicolai at redhat.com> made a comment on [bug 719783|https://bugzilla.redhat.com/show_bug.cgi?id=719783]

Detected problem on upstream Drools project version 5.2.0.Final when a rollback is executed on a Drools session, it fails to restore the RuleFlowNode instance, leaving a null reference to workingmemory attribute.


Problem will be tracked by the following Jira: JBRULES-3138

Provided a workaround until upstream version is released.

> NullPointerException on RuleFlowGroupImpl after a rollback on a StatefulKnowledgeSession
> ----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3138
>                 URL: https://issues.jboss.org/browse/JBRULES-3138
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.2.0.Final
>            Reporter: Cristiano Nicolai
>            Assignee: Mark Proctor
>         Attachments: process-test.zip
>
>
> After executing some action that causes the StatefulKnowledgeSession to rollback, a NullPointerExption is throw on RuleFlowGroupImpl.setActive(RuleFlowGroupImpl.java:121) when it tries to use the workingMemory object. It seems that RuleFlowGroupImpl is not correctly deserialized/recreated after the rollback.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 02:44:23 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Wed, 13 Jul 2011 02:44:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1232)
 :test-connection-in-pool is "useless"
In-Reply-To: <194589846.42083.1310133683764.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1425927915.49869.1310539463664.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefano Maestri commented on AS7-1232:
--------------------------------------

the problem is due to a wrong jndi name generation when ds are registered in ana internal management repository to call runtime operation.
Fixed and pull request asked. Please note that now we have 3 possible answer for this operation:


"outcome" => "failed",
    "failure-description" => "failed to set invoke operation: failed to match pool. Check JndiName: java:jboss/datrces/ExampleDS",
    "rolled-back" => true

OR

"outcome" => "success",
    "result" => [true]

OR

 "outcome" => "success",
    "result" => [false]


Last one is saying: "operation invoked, but connection tested is not valid" that should be your case.


> :test-connection-in-pool is "useless"
> -------------------------------------
>
>                 Key: AS7-1232
>                 URL: https://issues.jboss.org/browse/AS7-1232
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 7.0.0.CR1
>            Reporter: Heiko Rupp
>            Assignee: Stefano Maestri
>
> I have defined a datasource like this:
> [domain at localhost:9999 data-source=postresDS] :read-resource
> {
>     "outcome" => "success",
>     "result" => {
>         "connection-url" => "jdbc:yadayada",
>         "driver-name" => "postgresql-9.0-801.jdbc4.jar",
> So obviously with an invalid driver.
> But still I get 
> [domain at localhost:9999 data-source=postresDS] :test-connection-in-pool
> {
>     "outcome" => "success",
>     "result" => undefined
> }
> which makes imho no sense.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 02:49:23 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Wed, 13 Jul 2011 02:49:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1232)
 :test-connection-in-pool is "useless"
In-Reply-To: <194589846.42083.1310133683764.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1595751561.49882.1310539763673.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Rupp commented on AS7-1232:
---------------------------------

Couldn't you make the last also a "outcome => failure" with a failure description of "connection not valid" and perhaps a "rolled-back=>false". This way success is only returned if the connection is valid (default case) and otherwise return failure (for whatever reason).

> :test-connection-in-pool is "useless"
> -------------------------------------
>
>                 Key: AS7-1232
>                 URL: https://issues.jboss.org/browse/AS7-1232
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 7.0.0.CR1
>            Reporter: Heiko Rupp
>            Assignee: Stefano Maestri
>
> I have defined a datasource like this:
> [domain at localhost:9999 data-source=postresDS] :read-resource
> {
>     "outcome" => "success",
>     "result" => {
>         "connection-url" => "jdbc:yadayada",
>         "driver-name" => "postgresql-9.0-801.jdbc4.jar",
> So obviously with an invalid driver.
> But still I get 
> [domain at localhost:9999 data-source=postresDS] :test-connection-in-pool
> {
>     "outcome" => "success",
>     "result" => undefined
> }
> which makes imho no sense.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 02:51:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Wed, 13 Jul 2011 02:51:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-1269) Injection via @EJB
	fails
In-Reply-To: <1010288523.49667.1310520923613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1462443044.49886.1310539883620.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas closed AS7-1269.
-------------------------------

         Assignee: Stuart Douglas
    Fix Version/s: 7.0.1.Final
                   7.1.0.Alpha1
       Resolution: Done


> Injection via @EJB fails
> ------------------------
>
>                 Key: AS7-1269
>                 URL: https://issues.jboss.org/browse/AS7-1269
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: John Ament
>            Assignee: Stuart Douglas
>             Fix For: 7.0.1.Final, 7.1.0.Alpha1
>
>
> https://gist.github.com/1079559

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 03:57:23 2011
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 13 Jul 2011 03:57:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3116) Performance
 Regression due to mvel ParserContext now set,
 resulting in CompositeClassLoader loads
In-Reply-To: <2041340836.33655.1309784843699.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1533431345.49933.1310543843729.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Mark Proctor commented on JBRULES-3116:
---------------------------------------

The MVEL author is looking into this. His plan is likely to pre-index Classes in a package by scanning the disk and jars.

> Performance Regression due to mvel ParserContext now set, resulting in CompositeClassLoader loads
> -------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3116
>                 URL: https://issues.jboss.org/browse/JBRULES-3116
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler
>    Affects Versions: 5.2.0.Final
>            Reporter: Fabian Lange
>            Assignee: Mark Proctor
>         Attachments: abstractParser-bug1.png
>
>
> I observed this issue already with 5.1, but now had time to verify it with 5.2.
> Initial compilation time has exploded with those versions.
> I have with the same test cases with 5.2 this:
> {{org.drools.util.CompositeClassLoader$CachingLoader.load}} taking a total of 42 seconds
> With 5.0 (where this Caching was not yet implemented)
> I had a total time of less than 5 seconds spend in the ClassLoading.
> The reason for this took me a while to find, but now I do have it:
> {{org.mvel2.compiler.AbstractParser.createPropertyToken}}
> is invoking {{hasImports()}} and {{getImport()}} on the ParseContext if not null:
> see:
> https://github.com/mikebrock/mvel/blob/master/src/main/java/org/mvel2/compiler/AbstractParser.java#L1292
> Those in turn are invoking {{org.mvel2.ParserConfiguration.checkForDynamicImport}}
> which invokes {{org.drools.util.CompositeClassLoader.loadClass}}
> This is invoked on my table for expressions like this: "{{age >= 16}}"
> So the {{org.drools.util.CompositeClassLoader$CachingLoader.load}}
> will look for a class called "age" and a class called "16". Because the class not exists null/false are returned from the callchain.
> However neither the {{CachingLoader}}, nor the Map in {{AbstractParser}} will cache the negative result. Causing this to happen for each row in my decisiontable.
> And in 5.0 the whole part of the callgraph is not there.
> I figured out, that in 5.0 versions, the {{AbstractParser}} never had a parse context in createPropertyToken
> This might be because of the inconsistent usage of
> {code}
> protected static ThreadLocal<ParserContext> parserContext;
> protected ParserContext pCtx;
> {code}
> So where does us leave this?
> A possible easy solution would be to add the "negative" lookups to the CachingLoader.
> However I would like to have doublechecked if the change in Abstract Parser was intentional and is now working correctly. Thus invoking the checkDynamicImports a lot is correct. Is it really the case that the parser needs to check for each literal this dynamic import thing? it obviously didnt do before.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 06:32:23 2011
From: jira-events at lists.jboss.org (Tom Ross (JIRA))
Date: Wed, 13 Jul 2011 06:32:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1887) Messages lost
 during orderly shutdown of JBoss Messaging server
Message-ID: <1202846556.50102.1310553143712.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Messages lost during orderly shutdown of JBoss Messaging server
---------------------------------------------------------------

                 Key: JBMESSAGING-1887
                 URL: https://issues.jboss.org/browse/JBMESSAGING-1887
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core
    Affects Versions: 1.4.8.SP1, 1.4.7.GA
         Environment: JBoss EAP 5.1.0
            Reporter: Tom Ross
            Assignee: Yong Hao Gao


During orderly shutdown of JBoss EAP server/Messaging server messages are being lost.  

In the above test case a publisher is publishing messages to a topic (which has several durable subscribers) on a JBM server while the user uses control-c to shutdown the server or runs shutdown.sh script.

The server will first shutdown the topic service (subscribers) and then the server peer and post office. When the subscribers has been just shutdown but the server peer and post office is still alive, if a message are sent in to the post office and post office tries to route the message to subscribers, the subscribers are already deactivated so it didn't get route.

In this case the post office does not throw any exceptions back to the publisher. Instead it returns without error.

Following message will apear in the log file:
(WorkerThread#1[192.168.1.110:56860]) Queue[37225610/2/2952-guest.mdbOne] is not active, returning null delivery for Reference[41396777574629398]:RELIABLE




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 07:15:24 2011
From: jira-events at lists.jboss.org (Ondrej Zizka (JIRA))
Date: Wed, 13 Jul 2011 07:15:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1264) Add schema references
 to standalone.xml, domain.xml, host.xml
In-Reply-To: <1620974387.48924.1310488763828.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1677776388.50279.1310555724548.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Ondrej Zizka updated AS7-1264:
------------------------------

        Description: 
It appears that users of Jboss 7 will be often modifying these configuration files as they fine tune their server and when they discover how to implement new features.

It seems quite surprising to me that these files do not have the schema references identified in the file header.  Any good XML editor would use those references to validate changes and new entries and thereby avoid a great deal of frustration for users and those who provide support for forum issues.

I realise that if jboss validated each xml file when starting up there would be performance penalty that may be unacceptable to many users.  A command-line switch could be used to either turn on xml validation (if the default were that no validation is performed) or conversely to turn off xml validation if the default state was that xml validation was on.

Personally I favor having a switch that turns off validation - to be used on production servers only.

If the schema/dtd files were published online and referenced within the configuration xml files, future changes to the schema structure would be "enforced" upon the user community as they attempted to use an out-of-date version when upgrading to a new version of JBoss AS 7. 

  was:
It appears that users of Jboss 7 will be often modifying these configuration files as they fine tune their server and when they discover how to implement new features.

It seems quite surprising to me that these files do not have the schema references identified in the file header.  Any good XML editor would use those references to validate changes and new entries and thereby avoid a great deal of frustration for users and those who provide support for forum issues.

I realise that if jboss validated each xml file when starting up there would be performance penalty that may be unacceptable to many users.  A command-line switch could be used to either turn on xml validation (if the default were that no validation is performed) or conversely to turn off xml validation if the default state was that xml validation was on.

Personally I favor having a switch that turns off validation - to be used on production servers only.

If the schema/dtd files were published online and referenced within the configuration xml files, future changes to the schema structure would be "enforced" upon the user community as they attempted to use an out-of-date version when upgrading to a new version of Jboss 7. 

    Forum Reference: http://community.jboss.org/thread/169301  (was: http://community.jboss.org/thread/169301)


> Add schema references to standalone.xml, domain.xml, host.xml
> -------------------------------------------------------------
>
>                 Key: AS7-1264
>                 URL: https://issues.jboss.org/browse/AS7-1264
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>    Affects Versions: 7.0.0.CR1
>            Reporter: Gerry Matte
>            Assignee: Brian Stansberry
>              Labels: domain, host, standalone, xml, xmlns
>
> It appears that users of Jboss 7 will be often modifying these configuration files as they fine tune their server and when they discover how to implement new features.
> It seems quite surprising to me that these files do not have the schema references identified in the file header.  Any good XML editor would use those references to validate changes and new entries and thereby avoid a great deal of frustration for users and those who provide support for forum issues.
> I realise that if jboss validated each xml file when starting up there would be performance penalty that may be unacceptable to many users.  A command-line switch could be used to either turn on xml validation (if the default were that no validation is performed) or conversely to turn off xml validation if the default state was that xml validation was on.
> Personally I favor having a switch that turns off validation - to be used on production servers only.
> If the schema/dtd files were published online and referenced within the configuration xml files, future changes to the schema structure would be "enforced" upon the user community as they attempted to use an out-of-date version when upgrading to a new version of JBoss AS 7. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 09:28:23 2011
From: jira-events at lists.jboss.org (Justin Wyer (JIRA))
Date: Wed, 13 Jul 2011 09:28:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1273) Applications (or
 their libraries) containing persistence units with the connection defined
 inline via properties case deployment failure.
Message-ID: <1479473773.50517.1310563703689.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Applications (or their libraries) containing persistence units with the connection defined inline via properties case deployment failure.
-----------------------------------------------------------------------------------------------------------------------------------------

                 Key: AS7-1273
                 URL: https://issues.jboss.org/browse/AS7-1273
             Project: Application Server 7
          Issue Type: Bug
          Components: JPA / Hibernate
    Affects Versions: 7.0.0.Final, 7.1.0.Alpha1
            Reporter: Justin Wyer
            Assignee: Scott Marlow


Persistence units defined as follows https://github.com/droolsjbpm/jbpm/blob/master/jbpm-human-task/src/main/resources/META-INF/persistence.xml causes deployment to fail due to the fact that no <jta-data-source> or <non-jta-data-source> is present, but none should be present as the datasource has been defined via the properties.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 09:28:23 2011
From: jira-events at lists.jboss.org (Justin Wyer (JIRA))
Date: Wed, 13 Jul 2011 09:28:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1273) Applications (or
 their libraries) containing persistence units with the connection defined
 inline via properties cause deployment failure.
In-Reply-To: <1479473773.50517.1310563703689.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1173950675.50521.1310563703783.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Justin Wyer updated AS7-1273:
-----------------------------

    Summary: Applications (or their libraries) containing persistence units with the connection defined inline via properties cause deployment failure.  (was: Applications (or their libraries) containing persistence units with the connection defined inline via properties case deployment failure.)


> Applications (or their libraries) containing persistence units with the connection defined inline via properties cause deployment failure.
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1273
>                 URL: https://issues.jboss.org/browse/AS7-1273
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Final, 7.1.0.Alpha1
>            Reporter: Justin Wyer
>            Assignee: Scott Marlow
>              Labels: as7, jpa
>
> Persistence units defined as follows https://github.com/droolsjbpm/jbpm/blob/master/jbpm-human-task/src/main/resources/META-INF/persistence.xml causes deployment to fail due to the fact that no <jta-data-source> or <non-jta-data-source> is present, but none should be present as the datasource has been defined via the properties.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 09:30:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 13 Jul 2011 09:30:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1273) Applications (or
 their libraries) containing persistence units with the connection defined
 inline via properties cause deployment failure.
In-Reply-To: <1479473773.50517.1310563703689.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1538880650.50530.1310563823767.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on AS7-1273:
-----------------------------------

some IRC discussion is here:  http://echelog.matzon.dk/logs/browse/jboss-as7/1310508000

> Applications (or their libraries) containing persistence units with the connection defined inline via properties cause deployment failure.
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1273
>                 URL: https://issues.jboss.org/browse/AS7-1273
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Final, 7.1.0.Alpha1
>            Reporter: Justin Wyer
>            Assignee: Scott Marlow
>              Labels: as7, jpa
>
> Persistence units defined as follows https://github.com/droolsjbpm/jbpm/blob/master/jbpm-human-task/src/main/resources/META-INF/persistence.xml causes deployment to fail due to the fact that no <jta-data-source> or <non-jta-data-source> is present, but none should be present as the datasource has been defined via the properties.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 09:52:23 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Wed, 13 Jul 2011 09:52:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1887) Messages
 lost during orderly shutdown of JBoss Messaging server
In-Reply-To: <1202846556.50102.1310553143712.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <899211291.50587.1310565143850.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao commented on JBMESSAGING-1887:
-------------------------------------------

The post office should throw a JMSException in that case. For a queue sender, on receiving this example means the message should be sent again. However for a topic publisher, it needs to know which subscribers haven't got the message. 

I think we can wrap such information in the exception and throw back to the publisher.

Howard

> Messages lost during orderly shutdown of JBoss Messaging server
> ---------------------------------------------------------------
>
>                 Key: JBMESSAGING-1887
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1887
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.7.GA, 1.4.8.SP1
>         Environment: JBoss EAP 5.1.0
>            Reporter: Tom Ross
>            Assignee: Yong Hao Gao
>
> During orderly shutdown of JBoss EAP server/Messaging server messages are being lost.  
> In the above test case a publisher is publishing messages to a topic (which has several durable subscribers) on a JBM server while the user uses control-c to shutdown the server or runs shutdown.sh script.
> The server will first shutdown the topic service (subscribers) and then the server peer and post office. When the subscribers has been just shutdown but the server peer and post office is still alive, if a message are sent in to the post office and post office tries to route the message to subscribers, the subscribers are already deactivated so it didn't get route.
> In this case the post office does not throw any exceptions back to the publisher. Instead it returns without error.
> Following message will apear in the log file:
> (WorkerThread#1[192.168.1.110:56860]) Queue[37225610/2/2952-guest.mdbOne] is not active, returning null delivery for Reference[41396777574629398]:RELIABLE

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 09:58:23 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Wed, 13 Jul 2011 09:58:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1887) Messages lost
 during orderly shutdown of JBoss Messaging server
In-Reply-To: <1202846556.50102.1310553143712.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1522511562.50599.1310565503675.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao updated JBMESSAGING-1887:
--------------------------------------

        Fix Version/s: 1.4.0.SP3.CP14
                       1.4.8.SP2
    Affects Version/s: 1.4.0.SP3.CP13


> Messages lost during orderly shutdown of JBoss Messaging server
> ---------------------------------------------------------------
>
>                 Key: JBMESSAGING-1887
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1887
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP13, 1.4.7.GA, 1.4.8.SP1
>         Environment: JBoss EAP 5.1.0
>            Reporter: Tom Ross
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP14, 1.4.8.SP2
>
>
> During orderly shutdown of JBoss EAP server/Messaging server messages are being lost.  
> In the above test case a publisher is publishing messages to a topic (which has several durable subscribers) on a JBM server while the user uses control-c to shutdown the server or runs shutdown.sh script.
> The server will first shutdown the topic service (subscribers) and then the server peer and post office. When the subscribers has been just shutdown but the server peer and post office is still alive, if a message are sent in to the post office and post office tries to route the message to subscribers, the subscribers are already deactivated so it didn't get route.
> In this case the post office does not throw any exceptions back to the publisher. Instead it returns without error.
> Following message will apear in the log file:
> (WorkerThread#1[192.168.1.110:56860]) Queue[37225610/2/2952-guest.mdbOne] is not active, returning null delivery for Reference[41396777574629398]:RELIABLE

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 10:02:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 13 Jul 2011 10:02:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1273) Applications (or
 their libraries) containing persistence units with the connection defined
 inline via properties cause deployment failure.
In-Reply-To: <1479473773.50517.1310563703689.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <785099848.50617.1310565743657.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on AS7-1273:
-----------------------------------

If the persistence unit doesn't specify a datasource (jta or non-jta) and there isn't a default datasource configured in standalone.xml/domain.xml, we should not deploy the persistence unit definition (just ignore it with a logged warning).

At least, that seems like the right thing to do with regard to this case.  Target code site to fix is org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.addPuService()

> Applications (or their libraries) containing persistence units with the connection defined inline via properties cause deployment failure.
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1273
>                 URL: https://issues.jboss.org/browse/AS7-1273
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Final, 7.1.0.Alpha1
>            Reporter: Justin Wyer
>            Assignee: Scott Marlow
>              Labels: as7, jpa
>
> Persistence units defined as follows https://github.com/droolsjbpm/jbpm/blob/master/jbpm-human-task/src/main/resources/META-INF/persistence.xml causes deployment to fail due to the fact that no <jta-data-source> or <non-jta-data-source> is present, but none should be present as the datasource has been defined via the properties.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 10:04:23 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Wed, 13 Jul 2011 10:04:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1887) Messages
 lost during orderly shutdown of JBoss Messaging server
In-Reply-To: <1202846556.50102.1310553143712.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <913411345.50622.1310565863690.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao commented on JBMESSAGING-1887:
-------------------------------------------

Actually on second thought, that might not be helpful for a publisher because a publisher cannot re-sent the message to some of the subscribers to the topic. It only can resent the message to the topic. But doing so all subscribers will receive the message again -- including ones that have successfully received it before.


> Messages lost during orderly shutdown of JBoss Messaging server
> ---------------------------------------------------------------
>
>                 Key: JBMESSAGING-1887
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1887
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP13, 1.4.7.GA, 1.4.8.SP1
>         Environment: JBoss EAP 5.1.0
>            Reporter: Tom Ross
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP14, 1.4.8.SP2
>
>
> During orderly shutdown of JBoss EAP server/Messaging server messages are being lost.  
> In the above test case a publisher is publishing messages to a topic (which has several durable subscribers) on a JBM server while the user uses control-c to shutdown the server or runs shutdown.sh script.
> The server will first shutdown the topic service (subscribers) and then the server peer and post office. When the subscribers has been just shutdown but the server peer and post office is still alive, if a message are sent in to the post office and post office tries to route the message to subscribers, the subscribers are already deactivated so it didn't get route.
> In this case the post office does not throw any exceptions back to the publisher. Instead it returns without error.
> Following message will apear in the log file:
> (WorkerThread#1[192.168.1.110:56860]) Queue[37225610/2/2952-guest.mdbOne] is not active, returning null delivery for Reference[41396777574629398]:RELIABLE

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 10:36:25 2011
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Wed, 13 Jul 2011 10:36:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1268) Can't update
 subhandler on async handler
In-Reply-To: <809971781.49345.1310505203625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <828073642.50826.1310567785276.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stan Silvert reassigned AS7-1268:
---------------------------------

    Assignee: Stan Silvert  (was: David Lloyd)


> Can't update subhandler on async handler
> ----------------------------------------
>
>                 Key: AS7-1268
>                 URL: https://issues.jboss.org/browse/AS7-1268
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.1.0.Alpha1
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>
> David, sorry if I'm assigning to the wrong person.  I guess this could be a CLI bug.
> [standalone at localhost:9999 /] cd subsystem=logging/async-handler=ASYNC
> [standalone at localhost:9999 async-handler=ASYNC] :read-resource(recursive=true)
> {
>     "outcome" => "success",
>     "result" => {
>         "level" => "INFO",
>         "overflow-action" => "BLOCK",
>         "queue-length" => 1024,
>         "subhandlers" => ["FILE"]
>     }
> }
> [standalone at localhost:9999 async-handler=ASYNC] :update-properties(subhandlers=["CONSOLE"])
> {"outcome" => "success"}
> [standalone at localhost:9999 async-handler=ASYNC] :read-resource(recursive=true)
> {
>     "outcome" => "success",
>     "result" => {
>         "level" => "INFO",
>         "overflow-action" => "BLOCK",
>         "queue-length" => 1024,
>         "subhandlers" => ["FILE"]
>     }
> }

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 10:46:25 2011
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 13 Jul 2011 10:46:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-678) Upgrade Nexus to
	1.9.2
In-Reply-To: <1378639576.20031.1302539973097.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2139443249.50892.1310568385154.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Gier updated JBBUILD-678:
------------------------------

            Summary: Upgrade Nexus to 1.9.2  (was: Upgrade Nexus to 1.9.1)
        Description: We are experiencing a few bugs in Nexus 1.9.0.2, as described in the build forum.  I don't consider these critical, but we should still look into upgrading to 1.9.2 soon after it becomes available.  (was: We are experiencing a few bugs in Nexus 1.9.0.2, as described in the build forum.  I don't consider these critical, but we should still look into upgrading to 1.9.1 soon after it becomes available.)
    Forum Reference: http://community.jboss.org/thread/165065  (was: http://community.jboss.org/thread/165065)


There is also an issue related to cleanup of snapshots and other files.  This is fixed in the current versions of Nexus.
https://issues.sonatype.org/browse/NEXUS-4122


> Upgrade Nexus to 1.9.2
> ----------------------
>
>                 Key: JBBUILD-678
>                 URL: https://issues.jboss.org/browse/JBBUILD-678
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Artifact Repositories
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>            Priority: Minor
>             Fix For: Build Support 2011
>
>
> We are experiencing a few bugs in Nexus 1.9.0.2, as described in the build forum.  I don't consider these critical, but we should still look into upgrading to 1.9.2 soon after it becomes available.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 10:56:23 2011
From: jira-events at lists.jboss.org (Nick Bruno (JIRA))
Date: Wed, 13 Jul 2011 10:56:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3140)
 NullPointerException thrown on JPA synchronization.afterCompletion()
 clearProcessInstances()
Message-ID: <2030892173.50899.1310568983737.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

NullPointerException thrown on JPA synchronization.afterCompletion() clearProcessInstances()
--------------------------------------------------------------------------------------------

                 Key: JBRULES-3140
                 URL: https://issues.jboss.org/browse/JBRULES-3140
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.2.0.Final
            Reporter: Nick Bruno
            Assignee: Mark Proctor


In org.drools.persistence.SingleSessionCommandService$SynchronizationImpl.afterCompletion(), the following generates a NullPointerException when no processes are implemented.
{noformat}if ( ksession != null ) {
     ((InternalKnowledgeRuntime) ksession).getProcessRuntime().clearProcessInstances(); // NullPointerException
     ((JPAWorkItemManager) ksession.getWorkItemManager()).clearWorkItems();
}
{noformat} 
The fix is to grab the InternalProcessRuntime to a local variable and test if it is null before calling clearProcessInstances(), as so:
{noformat}InternalProcessRuntime ipr = ((InternalKnowledgeRuntime) ksession).getProcessRuntime();
if( ipr != null) {
     ipr.clearProcessInstances();
}{noformat} 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 10:56:23 2011
From: jira-events at lists.jboss.org (Nick Bruno (JIRA))
Date: Wed, 13 Jul 2011 10:56:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-3140)
 NullPointerException thrown on JPA synchronization.afterCompletion() due to
 clearProcessInstances()
In-Reply-To: <2030892173.50899.1310568983737.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1628323469.50903.1310568983862.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Nick Bruno updated JBRULES-3140:
--------------------------------

    Summary: NullPointerException thrown on JPA synchronization.afterCompletion() due to clearProcessInstances()  (was: NullPointerException thrown on JPA synchronization.afterCompletion() clearProcessInstances())


> NullPointerException thrown on JPA synchronization.afterCompletion() due to clearProcessInstances()
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3140
>                 URL: https://issues.jboss.org/browse/JBRULES-3140
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.2.0.Final
>            Reporter: Nick Bruno
>            Assignee: Mark Proctor
>              Labels: patch
>
> In org.drools.persistence.SingleSessionCommandService$SynchronizationImpl.afterCompletion(), the following generates a NullPointerException when no processes are implemented.
> {noformat}if ( ksession != null ) {
>      ((InternalKnowledgeRuntime) ksession).getProcessRuntime().clearProcessInstances(); // NullPointerException
>      ((JPAWorkItemManager) ksession.getWorkItemManager()).clearWorkItems();
> }
> {noformat} 
> The fix is to grab the InternalProcessRuntime to a local variable and test if it is null before calling clearProcessInstances(), as so:
> {noformat}InternalProcessRuntime ipr = ((InternalKnowledgeRuntime) ksession).getProcessRuntime();
> if( ipr != null) {
>      ipr.clearProcessInstances();
> }{noformat} 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 11:14:23 2011
From: jira-events at lists.jboss.org (Tarley Lana (JIRA))
Date: Wed, 13 Jul 2011 11:14:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-3125) Including
 compression support (gzip) to optimize network traffic between server and
 agent
In-Reply-To: <1702273616.46339.1310408184473.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <87946194.50934.1310570063683.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Tarley Lana updated JBRULES-3125:
---------------------------------

        Description: 
This patch makes the class "org.drools.io.impl.UrlResource" support the download of compressed rules. Below are the settings required to enable transmission of compressed rules over the network:

SERVER SIDE

1) In this example I used the "drools-5.1.1-guvnor-standalone" as a rule base;
2) Include the following line in the file "{JBOSS-HOME}\server\default\deploy\jboss-web.deployer\server.xml" to enable compression of the rules:

<Connector port="8080" address="${jboss.bind.address}" 
		maxThreads="250" maxHttpHeaderSize="8192" 
		emptySessionPath="true" protocol="HTTP/1.1" 
		enableLookups="false" redirectPort="8443" acceptCount="100" 
		connectionTimeout="20000" disableUploadTimeout="true" compression="force"
		compressableMimeType="application/x-download" 
		compressionMinSize="100"/>

CLIENT SIDE
1) Set the "ChangeSet.xml" for the rules of the server as the example below:

<change-set xmlns='http://drools.org/drools-5.0/change-set'
xmlns:xs='http://www.w3.org/2001/XMLSchema-instance'
	xs:schemaLocation='http://drools.org/drools-5.0/change-set  http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-api/src/main/resources/change-set-1.0.0.xsd' >
<add>
   <resource source='http://127.0.0.1:8080/drools-guvnor/org.drools.guvnor.Guvnor/package/app/LATEST'
 type='PKG' basicAuthentication='enabled' username='usr' password='psw'/>
</add>
</change-set>


  was:
This patch makes the class "org.drools.io.impl.UrlResource" support the download of compressed rules. Below are the settings required to enable transmission of compressed rules over the network:

SERVER SIDE

1) In this example I used the "drools-5.1.1-guvnor-standalone" as a rule base;
2) Include the following line in the file "{JBOSS-HOME}\server\default\deploy\jboss-web.deployer\server.xml" to enable compression of the rules:

<Connector port="8080" address="${jboss.bind.address}" 
		maxThreads="250" maxHttpHeaderSize="8192" 
		emptySessionPath="true" protocol="HTTP/1.1" 
		enableLookups="false" redirectPort="8443" acceptCount="100" 
		connectionTimeout="20000" disableUploadTimeout="true" compression="force"
		compressableMimeType="application/x-download" 
		compressionMinSize="100"/>

CLIENT SIDE
1) Set the "ChangeSet.xml" for the rules of the server as the example below:

<change-set xmlns='http://drools.org/drools-5.0/change-set'
xmlns:xs='http://www.w3.org/2001/XMLSchema-instance'
	xs:schemaLocation='http://drools.org/drools-5.0/change-set  http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-api/src/main/resources/change-set-1.0.0.xsd' >
<add>
   <!-- ARKHI / Rackspace -->
   <resource source='http://127.0.0.1:8080/drools-guvnor/org.drools.guvnor.Guvnor/package/araujo.ecf/LATEST'
 type='PKG' basicAuthentication='enabled' username='ecf' password='senha'/>
</add>
</change-set>


    Forum Reference: http://drools.46999.n3.nabble.com/Is-there-any-way-to-compress-gzip-the-rules-package-to-optimize-network-traffic-between-server-and-a-td3129297.html  (was: http://drools.46999.n3.nabble.com/Is-there-any-way-to-compress-gzip-the-rules-package-to-optimize-network-traffic-between-server-and-a-td3129297.html)


> Including compression support (gzip) to optimize network traffic between server and agent
> -----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3125
>                 URL: https://issues.jboss.org/browse/JBRULES-3125
>             Project: Drools
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.1.1.FINAL
>         Environment: drools-5.1.1-guvnor-standalone, jboss-4.2.3.GA
>            Reporter: Tarley Lana
>            Assignee: Mark Proctor
>              Labels: Compress, Compressed
>         Attachments: patch.txt
>
>
> This patch makes the class "org.drools.io.impl.UrlResource" support the download of compressed rules. Below are the settings required to enable transmission of compressed rules over the network:
> SERVER SIDE
> 1) In this example I used the "drools-5.1.1-guvnor-standalone" as a rule base;
> 2) Include the following line in the file "{JBOSS-HOME}\server\default\deploy\jboss-web.deployer\server.xml" to enable compression of the rules:
> <Connector port="8080" address="${jboss.bind.address}" 
> 		maxThreads="250" maxHttpHeaderSize="8192" 
> 		emptySessionPath="true" protocol="HTTP/1.1" 
> 		enableLookups="false" redirectPort="8443" acceptCount="100" 
> 		connectionTimeout="20000" disableUploadTimeout="true" compression="force"
> 		compressableMimeType="application/x-download" 
> 		compressionMinSize="100"/>
> CLIENT SIDE
> 1) Set the "ChangeSet.xml" for the rules of the server as the example below:
> <change-set xmlns='http://drools.org/drools-5.0/change-set'
> xmlns:xs='http://www.w3.org/2001/XMLSchema-instance'
> 	xs:schemaLocation='http://drools.org/drools-5.0/change-set  http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-api/src/main/resources/change-set-1.0.0.xsd' >
> <add>
>    <resource source='http://127.0.0.1:8080/drools-guvnor/org.drools.guvnor.Guvnor/package/app/LATEST'
>  type='PKG' basicAuthentication='enabled' username='usr' password='psw'/>
> </add>
> </change-set>

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 11:23:23 2011
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Wed, 13 Jul 2011 11:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBBUILD-678) Upgrade Nexus to
	1.9.2
In-Reply-To: <1378639576.20031.1302539973097.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <958593146.50941.1310570603639.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Gier reassigned JBBUILD-678:
---------------------------------

    Assignee: Vladimir Dosoudil  (was: Paul Gier)


> Upgrade Nexus to 1.9.2
> ----------------------
>
>                 Key: JBBUILD-678
>                 URL: https://issues.jboss.org/browse/JBBUILD-678
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Artifact Repositories
>            Reporter: Paul Gier
>            Assignee: Vladimir Dosoudil
>            Priority: Minor
>             Fix For: Build Support 2011
>
>
> We are experiencing a few bugs in Nexus 1.9.0.2, as described in the build forum.  I don't consider these critical, but we should still look into upgrading to 1.9.2 soon after it becomes available.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 15:50:23 2011
From: jira-events at lists.jboss.org (Max Rydahl Andersen (JIRA))
Date: Wed, 13 Jul 2011 15:50:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1274) consecutive add of
 deployment does not fail/warn
Message-ID: <1971864514.51501.1310586623702.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

consecutive add of deployment does not fail/warn 
-------------------------------------------------

                 Key: AS7-1274
                 URL: https://issues.jboss.org/browse/AS7-1274
             Project: Application Server 7
          Issue Type: Bug
            Reporter: Max Rydahl Andersen


using the scripts from https://github.com/maxandersen/as7scripting which simply just add contents and deploys it the following runs never fails.

from discussion on irc it should.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 15:54:23 2011
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ra=C3=BAl_Raja_Mart=C3=ADnez_=28JIRA=29?=)
Date: Wed, 13 Jul 2011 15:54:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1345) JDBC_PING fails to
 initialize table in mysql
Message-ID: <146558224.51504.1310586863624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

JDBC_PING fails to initialize table in mysql
--------------------------------------------

                 Key: JGRP-1345
                 URL: https://issues.jboss.org/browse/JGRP-1345
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.12
            Reporter: Ra?l Raja Mart?nez
            Assignee: Bela Ban


JDBC_PING fails to initialize DB table for discover when executing the following SQL:
CREATE TABLE JGROUPSPING (own_addr varchar(200) NOT NULL, cluster_name varchar(200) NOT NULL, ping_data varbinary(5000) DEFAULT NULL, PRIMARY KEY (own_addr, cluster_name) )

The statement results in "Specified key was too long; max key length is 1000 bytes"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Wed Jul 13 16:01:23 2011
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ra=C3=BAl_Raja_Mart=C3=ADnez_=28JIRA=29?=)
Date: Wed, 13 Jul 2011 16:01:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1345) JDBC_PING fails to
 initialize table in mysql
In-Reply-To: <146558224.51504.1310586863624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <700596572.51521.1310587283750.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Ra?l Raja Mart?nez commented on JGRP-1345:
------------------------------------------

the following override seems to solve the issue for a Innodb and utf8 db.

initialize_sql="CREATE TABLE IF NOT EXISTS JGROUPSPING (own_addr varchar(200) NOT NULL, cluster_name varchar(200) NOT NULL, ping_data varbinary(5000) DEFAULT NULL, PRIMARY KEY (own_addr, cluster_name)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin"



> JDBC_PING fails to initialize table in mysql
> --------------------------------------------
>
>                 Key: JGRP-1345
>                 URL: https://issues.jboss.org/browse/JGRP-1345
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.12
>            Reporter: Ra?l Raja Mart?nez
>            Assignee: Bela Ban
>
> JDBC_PING fails to initialize DB table for discover when executing the following SQL:
> CREATE TABLE JGROUPSPING (own_addr varchar(200) NOT NULL, cluster_name varchar(200) NOT NULL, ping_data varbinary(5000) DEFAULT NULL, PRIMARY KEY (own_addr, cluster_name) )
> The statement results in "Specified key was too long; max key length is 1000 bytes"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Wed Jul 13 17:27:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Wed, 13 Jul 2011 17:27:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1260) JGroups subsystem
 fails to setup some protocol stacks.
In-Reply-To: <1568744513.48245.1310478143759.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1388633569.51655.1310592443883.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro updated AS7-1260:
------------------------------

    Workaround Description: 
Replace <transport type="UDP" socket-binding="..."/>
with:
<transport type="UDP">
  <property name="bind_addr">insert-socket-binding-address-here</property>
  <property name="bind_port">insert-socket-binding-port-here</property>
  <property name="mcast_addr">insert-socket-binding-mcast-address-here</property>
  <property name="mcast_port">insert-socket-binding-mcast-port-here</property>
</transport>

and replace <transport type="TCP" socket-binding="..."/>
with:

<transport type="TCP">
  <property name="bind_addr">insert-socket-binding-address-here</property>
  <property name="bind_port">insert-socket-binding-port-here</property>
</transport>
                Workaround: [Workaround Exists]


> JGroups subsystem fails to setup some protocol stacks.
> ------------------------------------------------------
>
>                 Key: AS7-1260
>                 URL: https://issues.jboss.org/browse/AS7-1260
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.Final
>            Reporter: Trustin Lee
>            Assignee: Paul Ferraro
>            Priority: Critical
>
> After upgrading from AS 7.0.0.CR1 to AS 7.0.0.Final, I started to see an exception raised by org.jboss.as.clustering.jgroups.JChannelFactory:
> {code}
> 22:11:54,040 ERROR [stderr] (MSC service thread 1-1) java.lang.IllegalArgumentException: org.jgroups.ChannelException: unable to setup the protocol stack
> 22:11:54,040 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.ChannelProvider.getJGroupsChannel(ChannelProvider.java:71)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:273)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:226)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:254)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:148)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at java.lang.reflect.Method.invoke(Method.java:597)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:918)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:711)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:611)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:176)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:171)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.CacheImpl.start(CacheImpl.java:366)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:559)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:479)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:84)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:73)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:73)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at java.lang.Thread.run(Thread.java:680)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) Caused by: org.jgroups.ChannelException: unable to setup the protocol stack
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.init(JChannel.java:1728)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.<init>(JChannel.java:249)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.jgroups.JChannelFactory$JChannel.<init>(JChannelFactory.java:269)
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:69)
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.ChannelProvider.getJGroupsChannel(ChannelProvider.java:67)
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	... 26 more
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) Caused by: java.lang.IllegalArgumentException: the following properties in PING are not recognized: {bind_addr=192.168.0.196}
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.createLayer(Configurator.java:460)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.createProtocols(Configurator.java:393)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:88)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:55)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:534)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.init(JChannel.java:1725)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	... 30 more
> {code}
> (Actually, the exception was being swallowed by Infinispan, so I had to modify the source code in Infinispan.)
> Reverting back only the JGroups subsystem to 7.0.0.CR1 fixes the problem for UDP stack.  TCP stack still fails when configuring MPING:
> {code}
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) Caused by: java.lang.IllegalArgumentException: the following properties in MPING are not recognized: {start_port=0}
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.createLayer(Configurator.java:460)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.createProtocols(Configurator.java:393)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:88)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:55)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:534)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.JChannel.init(JChannel.java:1725)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	... 30 more
> {code}
> The offending subsystem configuration is:
> {code}
>         <subsystem xmlns="urn:jboss:domain:jgroups:1.0" default-stack="udp">
>             <stack name="udp">
>                 <transport type="UDP"
>                            socket-binding="jgroups-udp"
>                            default-executor="jgroups"
>                            oob-executor="jgroups-oob"
>                            timer-executor="jgroups-timer"/>
>                 <protocol type="PING"/>
>                 <protocol type="MERGE2"/>
>                 <protocol type="FD_SOCK"/>
>                 <protocol type="FD"/>
>                 <protocol type="VERIFY_SUSPECT"/>
>                 <protocol type="BARRIER"/>
>                 <protocol type="pbcast.NAKACK"/>
>                 <protocol type="UNICAST"/>
>                 <protocol type="pbcast.STABLE"/>
>                 <protocol type="VIEW_SYNC"/>
>                 <protocol type="pbcast.GMS"/>
>                 <protocol type="UFC"/>
>                 <protocol type="MFC"/>
>                 <protocol type="FRAG2"/>
>                 <protocol type="pbcast.STREAMING_STATE_TRANSFER"/>
>                 <protocol type="pbcast.FLUSH"/>
>             </stack>
>             <stack name="tcp">
>                 <transport type="TCP"
>                            socket-binding="jgroups-tcp"
>                            default-executor="jgroups"
>                            oob-executor="jgroups-oob"
>                            timer-executor="jgroups-timer"/>
>                 <protocol type="MPING" socket-binding="jgroups-mping"/>
>                 <protocol type="MERGE2"/>
>                 <protocol type="FD_SOCK"/>
>                 <protocol type="FD"/>
>                 <protocol type="VERIFY_SUSPECT"/>
>                 <protocol type="BARRIER"/>
>                 <protocol type="pbcast.NAKACK"/>
>                 <protocol type="UNICAST"/>
>                 <protocol type="pbcast.STABLE"/>
>                 <protocol type="VIEW_SYNC"/>
>                 <protocol type="pbcast.GMS"/>
>                 <protocol type="UFC"/>
>                 <protocol type="MFC"/>
>                 <protocol type="FRAG2"/>
>                 <protocol type="pbcast.STREAMING_STATE_TRANSFER"/>
>                 <protocol type="pbcast.FLUSH"/>
>             </stack>
>         </subsystem>
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 18:21:23 2011
From: jira-events at lists.jboss.org (Benjamin Browning (JIRA))
Date: Wed, 13 Jul 2011 18:21:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1275)
 ClassNotFoundException When Restarting Node In Cluster with Distributable
 App Deployed
Message-ID: <908967862.51711.1310595683786.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

ClassNotFoundException When Restarting Node In Cluster with Distributable App Deployed
--------------------------------------------------------------------------------------

                 Key: AS7-1275
                 URL: https://issues.jboss.org/browse/AS7-1275
             Project: Application Server 7
          Issue Type: Bug
    Affects Versions: 7.0.0.Final
            Reporter: Benjamin Browning


When restarting a node in a cluster with a <distributable/> app deployed I get the below stacktrace. See the Steps to Reproduce for the steps taken leading up to this stacktrace.

bbrowning at bbrowning-mbp:~/Downloads/jboss-as-web-7.0.0.Final$ bin/standalone.sh -server-config standalone-ha-2.xml -Djboss.server.data.dir=/tmp/node2 -Djgroups.bind_addr=127.0.0.2
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /Users/bbrowning/Downloads/jboss-as-web-7.0.0.Final

  JAVA: /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/bin/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

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

16:48:00,839 INFO  [org.jboss.modules] JBoss Modules version 1.0.1.GA
16:48:01,187 INFO  [org.jboss.msc] JBoss MSC version 1.0.0.GA
16:48:01,253 INFO  [org.jboss.as] JBoss AS 7.0.0.Final "Lightning" starting
16:48:02,465 INFO  [org.jboss.as] creating http management service using network interface (management) port (9990) securePort (-1)
16:48:02,474 INFO  [org.jboss.as.logging] Removing bootstrap log handlers
16:48:02,501 INFO  [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying JDBC-compliant driver class org.h2.Driver (version 1.2)
16:48:02,517 INFO  [org.jboss.as.clustering.infinispan.subsystem] (Controller Boot Thread) Activating Infinispan subsystem.
16:48:02,658 INFO  [org.jboss.as.clustering.jgroups.subsystem] (Controller Boot Thread) Activating JGroups subsystem.
16:48:02,695 INFO  [org.jboss.as.osgi] (Controller Boot Thread) Activating OSGi Subsystem
16:48:02,714 INFO  [org.jboss.as.naming] (Controller Boot Thread) Activating Naming Subsystem
16:48:02,726 INFO  [org.jboss.as.naming] (MSC service thread 1-6) Starting Naming Service 
16:48:02,737 INFO  [org.jboss.as.security] (Controller Boot Thread) Activating Security Subsystem
16:48:02,744 INFO  [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 3.2.0.Beta2
16:48:02,757 INFO  [org.xnio] (MSC service thread 1-2) XNIO Version 3.0.0.Beta3
16:48:02,773 INFO  [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.0.0.Beta3
16:48:02,910 INFO  [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-7) 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
16:48:02,938 INFO  [org.jboss.as.ee] (Controller Boot Thread) Activating EE subsystem
16:48:02,943 INFO  [org.jboss.as.jmx.JMXConnectorService] (MSC service thread 1-4) Starting remote JMX connector
16:48:02,986 INFO  [org.jboss.as.modcluster] (MSC service thread 1-8) Mod_cluster uses default load balancer provider
16:48:02,990 INFO  [org.jboss.as.remoting] (MSC service thread 1-1) Listening on /127.0.0.2:9999
16:48:03,089 INFO  [org.jboss.modcluster.ModClusterService] (MSC service thread 1-8) Initializing mod_cluster 1.1.2.Final
16:48:03,095 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-6) Starting Coyote HTTP/1.1 on http--127.0.0.2-8080
16:48:03,328 INFO  [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (MSC service thread 1-8) Listening to proxy advertisements on 224.0.1.105:23364
16:48:03,371 INFO  [org.jboss.as.connector] (MSC service thread 1-4) Starting JCA Subsystem (JBoss IronJacamar 1.0.0.CR2)
16:48:03,465 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) Bound data source [java:jboss/datasources/ExampleDS]
16:48:03,964 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) Starting deployment of "make-love-not.war"
16:48:03,972 INFO  [org.jboss.as.deployment] (MSC service thread 1-2) Started FileSystemDeploymentService for directory /Users/bbrowning/Downloads/jboss-as-web-7.0.0.Final/standalone/deployments
16:48:04,665 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN00078: Starting JGroups Channel
16:48:04,669 INFO  [org.jgroups.JChannel] (MSC service thread 1-5) JGroups version: 2.12.1.Final
16:48:04,733 ERROR [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN00084: Errors instantiating [org.jboss.as.clustering.infinispan.ChannelProvider]!  Not using a channel lookup.
16:48:04,734 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN00088: Unable to use any JGroups configuration mechanisms provided in properties {channelLookup=org.jboss.as.clustering.infinispan.ChannelProvider, channel-factory=org.jboss.as.clustering.jgroups.JChannelFactory at 34e5307e, id=bbrowning-mbp-web}.  Using default JGroups configuration!
16:48:04,740 INFO  [org.jgroups.JChannel] (MSC service thread 1-5) JGroups version: 2.12.1.Final
16:48:04,928 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-5) receive buffer of socket java.net.DatagramSocket at 1d1d2b8 was set to 20MB, but the OS only allocated 65.51KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
16:48:04,928 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-5) receive buffer of socket java.net.MulticastSocket at 76612ef6 was set to 25MB, but the OS only allocated 65.51KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
16:48:05,021 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN00094: Received new cluster view: [bbrowning-mbp-29051|3] [bbrowning-mbp-29051, bbrowning-mbp-40805]
16:48:05,069 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN00079: Cache local address is bbrowning-mbp-40805, physical addresses are [127.0.0.2:50060]
16:48:05,069 INFO  [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-5) ISPN00128: Infinispan version: Infinispan 'Pagoa' 5.0.0.CR7
16:48:05,128 INFO  [org.infinispan.remoting.rpc.RpcManagerImpl] (MSC service thread 1-5) ISPN00074: Trying to fetch state from bbrowning-mbp-29051
16:48:05,240 INFO  [org.infinispan.remoting.rpc.RpcManagerImpl] (MSC service thread 1-5) ISPN00076: Successfully retrieved and applied state from bbrowning-mbp-29051
16:48:05,242 INFO  [org.infinispan.factories.ComponentRegistry] (MSC service thread 1-5) ISPN00128: Infinispan version: Infinispan 'Pagoa' 5.0.0.CR7
16:48:05,244 INFO  [org.jboss.as.clustering.infinispan.subsystem] (MSC service thread 1-5) Started repl cache from web container
16:48:05,276 INFO  [org.jboss.as.clustering.CoreGroupCommunicationService.web] (MSC service thread 1-4) Number of cluster members: 2
16:48:05,298 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (MSC service thread 1-4) ISPN00136: Execution error: org.infinispan.CacheException: Unable to unmarshall value
        at org.infinispan.marshall.MarshalledValue.deserialize0(MarshalledValue.java:148)
        at org.infinispan.marshall.MarshalledValue.deserialize(MarshalledValue.java:132)
        at org.infinispan.marshall.MarshalledValue.get(MarshalledValue.java:213)
        at org.infinispan.interceptors.MarshalledValueInterceptor.visitKeySetCommand(MarshalledValueInterceptor.java:204)
        at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
        at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
        at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
        at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
        at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:99)
        at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:64)
        at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
        at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
        at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
        at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
        at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
        at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:77)
        at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
        at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
        at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:274)
        at org.infinispan.CacheImpl.keySet(CacheImpl.java:261)
        at org.infinispan.AbstractDelegatingCache.keySet(AbstractDelegatingCache.java:261)
        at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getSessionIds(DistributedCacheManager.java:413)
        at org.jboss.as.web.session.DistributableSessionManager.initializeUnloadedSessions(DistributableSessionManager.java:299) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
        at org.jboss.as.web.session.DistributableSessionManager.start(DistributableSessionManager.java:201) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
        at org.apache.catalina.core.ContainerBase.setManager(ContainerBase.java:459) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.jboss.as.web.deployment.JBossContextConfig.processWebMetaData(JBossContextConfig.java:278) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
        at org.jboss.as.web.deployment.JBossContextConfig.applicationWebConfig(JBossContextConfig.java:166) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
        at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:417) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:182) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.jboss.as.web.deployment.JBossContextConfig.lifecycleEvent(JBossContextConfig.java:159) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
        at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:115) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.apache.catalina.core.StandardContext.start(StandardContext.java:3766) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
        at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
        at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
Caused by: java.lang.ClassNotFoundException: org.jboss.as.clustering.web.infinispan.DistributedCacheManagerFactory$SessionKeyImpl from [Module "deployment.make-love-not.war:main" from Service Module Loader]
        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
        at java.lang.Class.forName0(Native Method) [:1.6.0_26]
        at java.lang.Class.forName(Class.java:247) [:1.6.0_26]
        at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
        at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
        at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:888)
        at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1200)
        at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
        at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
        at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
        at org.infinispan.marshall.jboss.GenericJBossMarshaller.objectFromObjectStream(GenericJBossMarshaller.java:191)
        at org.infinispan.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:122)
        at org.infinispan.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:98)
        at org.infinispan.marshall.MarshalledValue.deserialize0(MarshalledValue.java:143)
        ... 41 more

16:48:05,306 ERROR [org.apache.catalina.session.ManagerBase] (MSC service thread 1-4) Unable to start manager.: org.infinispan.CacheException: Unable to unmarshall value
        at org.infinispan.marshall.MarshalledValue.deserialize0(MarshalledValue.java:148)
        at org.infinispan.marshall.MarshalledValue.deserialize(MarshalledValue.java:132)
        at org.infinispan.marshall.MarshalledValue.get(MarshalledValue.java:213)
        at org.infinispan.interceptors.MarshalledValueInterceptor.visitKeySetCommand(MarshalledValueInterceptor.java:204)
        at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
        at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
        at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
        at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
        at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:99)
        at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:64)
        at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
        at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
        at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
        at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
        at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
        at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:77)
        at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
        at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
        at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:274)
        at org.infinispan.CacheImpl.keySet(CacheImpl.java:261)
        at org.infinispan.AbstractDelegatingCache.keySet(AbstractDelegatingCache.java:261)
        at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getSessionIds(DistributedCacheManager.java:413)
        at org.jboss.as.web.session.DistributableSessionManager.initializeUnloadedSessions(DistributableSessionManager.java:299) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
        at org.jboss.as.web.session.DistributableSessionManager.start(DistributableSessionManager.java:201) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
        at org.apache.catalina.core.ContainerBase.setManager(ContainerBase.java:459) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.jboss.as.web.deployment.JBossContextConfig.processWebMetaData(JBossContextConfig.java:278) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
        at org.jboss.as.web.deployment.JBossContextConfig.applicationWebConfig(JBossContextConfig.java:166) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
        at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:417) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:182) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.jboss.as.web.deployment.JBossContextConfig.lifecycleEvent(JBossContextConfig.java:159) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
        at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:115) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.apache.catalina.core.StandardContext.start(StandardContext.java:3766) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
        at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
        at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
Caused by: java.lang.ClassNotFoundException: org.jboss.as.clustering.web.infinispan.DistributedCacheManagerFactory$SessionKeyImpl from [Module "deployment.make-love-not.war:main" from Service Module Loader]
        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
        at java.lang.Class.forName0(Native Method) [:1.6.0_26]
        at java.lang.Class.forName(Class.java:247) [:1.6.0_26]
        at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
        at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
        at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:888)
        at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1200)
        at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
        at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
        at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
        at org.infinispan.marshall.jboss.GenericJBossMarshaller.objectFromObjectStream(GenericJBossMarshaller.java:191)
        at org.infinispan.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:122)
        at org.infinispan.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:98)
        at org.infinispan.marshall.MarshalledValue.deserialize0(MarshalledValue.java:143)
        ... 41 more

16:48:05,313 ERROR [org.apache.catalina.core.ContainerBase] (MSC service thread 1-4) ContainerBase.setManager: start: : LifecycleException:  org.infinispan.CacheException: Unable to unmarshall value
        at org.jboss.as.web.session.DistributableSessionManager.start(DistributableSessionManager.java:213) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
        at org.apache.catalina.core.ContainerBase.setManager(ContainerBase.java:459) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.jboss.as.web.deployment.JBossContextConfig.processWebMetaData(JBossContextConfig.java:278) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
        at org.jboss.as.web.deployment.JBossContextConfig.applicationWebConfig(JBossContextConfig.java:166) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
        at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:417) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:182) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.jboss.as.web.deployment.JBossContextConfig.lifecycleEvent(JBossContextConfig.java:159) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
        at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:115) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.apache.catalina.core.StandardContext.start(StandardContext.java:3766) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
        at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
        at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]

16:48:05,385 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (MSC service thread 1-4) ISPN00136: Execution error: org.infinispan.CacheException: Unable to unmarshall value
        at org.infinispan.marshall.MarshalledValue.deserialize0(MarshalledValue.java:148)
        at org.infinispan.marshall.MarshalledValue.deserialize(MarshalledValue.java:132)
        at org.infinispan.marshall.MarshalledValue.get(MarshalledValue.java:213)
        at org.infinispan.interceptors.MarshalledValueInterceptor.visitKeySetCommand(MarshalledValueInterceptor.java:204)
        at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
        at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
        at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
        at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
        at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:99)
        at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:64)
        at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
        at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
        at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
        at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
        at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
        at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:77)
        at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
        at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
        at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:274)
        at org.infinispan.CacheImpl.keySet(CacheImpl.java:261)
        at org.infinispan.AbstractDelegatingCache.keySet(AbstractDelegatingCache.java:261)
        at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getSessionIds(DistributedCacheManager.java:413)
        at org.jboss.as.web.session.DistributableSessionManager.initializeUnloadedSessions(DistributableSessionManager.java:299) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
        at org.jboss.as.web.session.DistributableSessionManager.start(DistributableSessionManager.java:201) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
        at org.apache.catalina.core.StandardContext.start(StandardContext.java:3830) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
        at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
        at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
Caused by: java.lang.ClassNotFoundException: org.jboss.as.clustering.web.infinispan.DistributedCacheManagerFactory$SessionKeyImpl from [Module "deployment.make-love-not.war:main" from Service Module Loader]
        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
        at java.lang.Class.forName0(Native Method) [:1.6.0_26]
        at java.lang.Class.forName(Class.java:247) [:1.6.0_26]
        at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
        at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
        at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:888)
        at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1200)
        at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
        at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
        at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
        at org.infinispan.marshall.jboss.GenericJBossMarshaller.objectFromObjectStream(GenericJBossMarshaller.java:191)
        at org.infinispan.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:122)
        at org.infinispan.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:98)
        at org.infinispan.marshall.MarshalledValue.deserialize0(MarshalledValue.java:143)
        ... 34 more

16:48:05,392 ERROR [org.jboss.as.web.session.DistributableSessionManager.make-love-not] (MSC service thread 1-4) Unable to start manager.: org.infinispan.CacheException: Unable to unmarshall value
        at org.infinispan.marshall.MarshalledValue.deserialize0(MarshalledValue.java:148)
        at org.infinispan.marshall.MarshalledValue.deserialize(MarshalledValue.java:132)
        at org.infinispan.marshall.MarshalledValue.get(MarshalledValue.java:213)
        at org.infinispan.interceptors.MarshalledValueInterceptor.visitKeySetCommand(MarshalledValueInterceptor.java:204)
        at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
        at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
        at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
        at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
        at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:99)
        at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:64)
        at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
        at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
        at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
        at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
        at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
        at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
        at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:77)
        at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
        at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
        at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:274)
        at org.infinispan.CacheImpl.keySet(CacheImpl.java:261)
        at org.infinispan.AbstractDelegatingCache.keySet(AbstractDelegatingCache.java:261)
        at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getSessionIds(DistributedCacheManager.java:413)
        at org.jboss.as.web.session.DistributableSessionManager.initializeUnloadedSessions(DistributableSessionManager.java:299) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
        at org.jboss.as.web.session.DistributableSessionManager.start(DistributableSessionManager.java:201) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
        at org.apache.catalina.core.StandardContext.start(StandardContext.java:3830) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
        at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
        at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
Caused by: java.lang.ClassNotFoundException: org.jboss.as.clustering.web.infinispan.DistributedCacheManagerFactory$SessionKeyImpl from [Module "deployment.make-love-not.war:main" from Service Module Loader]
        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
        at java.lang.Class.forName0(Native Method) [:1.6.0_26]
        at java.lang.Class.forName(Class.java:247) [:1.6.0_26]
        at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
        at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
        at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:888)
        at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1200)
        at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
        at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
        at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
        at org.infinispan.marshall.jboss.GenericJBossMarshaller.objectFromObjectStream(GenericJBossMarshaller.java:191)
        at org.infinispan.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:122)
        at org.infinispan.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:98)
        at org.infinispan.marshall.MarshalledValue.deserialize0(MarshalledValue.java:143)
        ... 34 more

16:48:05,398 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-4) Context [/make-love-not] startup failed due to previous errors: LifecycleException:  org.infinispan.CacheException: Unable to unmarshall value
        at org.jboss.as.web.session.DistributableSessionManager.start(DistributableSessionManager.java:213) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
        at org.apache.catalina.core.StandardContext.start(StandardContext.java:3830) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
        at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
        at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]

16:48:05,399 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-4) Context [/make-love-not] startup failed due to previous errors
16:48:05,400 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-4) Exception during cleanup after start failed: java.lang.NullPointerException
        at org.jboss.as.web.session.DistributableSessionManager.stop(DistributableSessionManager.java:460)
        at org.apache.catalina.core.StandardContext.stop(StandardContext.java:3966)
        at org.apache.catalina.core.StandardContext.start(StandardContext.java:3888)
        at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70)
        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_26]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
        at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]

16:48:05,402 INFO  [org.apache.catalina.core.ContainerBase] (MSC service thread 1-4) Container org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/make-love-not].[jsp] has not been started
16:48:05,402 INFO  [org.apache.catalina.core.ContainerBase] (MSC service thread 1-4) Container org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/make-love-not].[default] has not been started
16:48:05,420 INFO  [org.jboss.web] (MSC service thread 1-4) registering web context: /make-love-not
16:48:05,430 INFO  [org.jboss.as.server.controller] (Controller Boot Thread) Deployed "make-love-not.war"
16:48:05,438 INFO  [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.0.Final "Lightning" started in 4906ms - Started 126 of 204 services (78 services are passive or on-demand)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 19:57:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Wed, 13 Jul 2011 19:57:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1256) <jar-file> in
 persistence.xml does not work
In-Reply-To: <1794857022.47048.1310429183676.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1798979169.51803.1310601443676.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved AS7-1256.
---------------------------------

    Fix Version/s: 7.0.0.Final
                       (was: 7.0.1.Final)
       Resolution: Done


> <jar-file> in persistence.xml does not work
> -------------------------------------------
>
>                 Key: AS7-1256
>                 URL: https://issues.jboss.org/browse/AS7-1256
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.CR1, 7.0.0.Final
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 7.0.0.Final
>
>
> HibernateAnnotationScanner does not correctly handle jar files other than the one containing persistence.xml

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 21:21:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Wed, 13 Jul 2011 21:21:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1276) When using
 Resteasy+Jackson jackson annotation are ignored
Message-ID: <1615132222.51870.1310606483884.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

When using Resteasy+Jackson jackson annotation are ignored
----------------------------------------------------------

                 Key: AS7-1276
                 URL: https://issues.jboss.org/browse/AS7-1276
             Project: Application Server 7
          Issue Type: Bug
    Affects Versions: 7.0.0.Final
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas
             Fix For: 7.0.1.Final




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 21:21:24 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Wed, 13 Jul 2011 21:21:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1276) When using
 Resteasy+Jackson jackson annotation are ignored
In-Reply-To: <1615132222.51870.1310606483884.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <185580396.51873.1310606484005.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas commented on AS7-1276:
-------------------------------------

For now a workaround is to add

Dependencies: org.codehaus.jackson.jackson-core-asl

to the apps MANIFEST.MF 

> When using Resteasy+Jackson jackson annotation are ignored
> ----------------------------------------------------------
>
>                 Key: AS7-1276
>                 URL: https://issues.jboss.org/browse/AS7-1276
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Final
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 7.0.1.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 13 21:32:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Wed, 13 Jul 2011 21:32:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1276) When using
 Resteasy+Jackson jackson annotation are ignored
In-Reply-To: <1615132222.51870.1310606483884.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1334482764.51923.1310607143622.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved AS7-1276.
---------------------------------

    Resolution: Done


> When using Resteasy+Jackson jackson annotation are ignored
> ----------------------------------------------------------
>
>                 Key: AS7-1276
>                 URL: https://issues.jboss.org/browse/AS7-1276
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Final
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 7.0.1.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 01:23:23 2011
From: jira-events at lists.jboss.org (Brad Davis (JIRA))
Date: Thu, 14 Jul 2011 01:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3141) Replace
 BinaryHeapPriorityQueue Implementation with
Message-ID: <436055328.52349.1310621003612.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Replace BinaryHeapPriorityQueue Implementation with 
----------------------------------------------------

                 Key: JBRULES-3141
                 URL: https://issues.jboss.org/browse/JBRULES-3141
             Project: Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Brad Davis
            Assignee: Mark Proctor




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 01:25:23 2011
From: jira-events at lists.jboss.org (Brad Davis (JIRA))
Date: Thu, 14 Jul 2011 01:25:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-3141) Replace
 BinaryHeapPriorityQueue Implementation with Java's PriorityBlockingQueue
In-Reply-To: <436055328.52349.1310621003612.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1540806016.52354.1310621123700.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brad Davis updated JBRULES-3141:
--------------------------------

        Summary: Replace BinaryHeapPriorityQueue Implementation with Java's PriorityBlockingQueue  (was: Replace BinaryHeapPriorityQueue Implementation with )
    Description: 
Attached is a PriorityQueue implementation I wrote last night to replace our home grown implementation.  I think it must have preceded the PriorityBlockingQueue that is already part of Java 5 & 6.

BinaryHeapPriorityQueueTest is where I plugged in this implementation.  Below are the results first running with our home grown BinaryHeapPriorityQueue, and then with the one I created, BasePriorityQueue.  There are numerous other benefits to using this as well, as it will fully implement the java.util.Collections API and therefore cleanup some other code elsewhere in our codebase.

The result for 10000 objects inserted and retracted was: 
BinaryHeapPriortyQueue
elapsedEnqueue = 32
elapsedDequeue = 294

BasePriorityQueue
elapsedEnqueue = 26
elapsedDequeue = 167



> Replace BinaryHeapPriorityQueue Implementation with Java's PriorityBlockingQueue
> --------------------------------------------------------------------------------
>
>                 Key: JBRULES-3141
>                 URL: https://issues.jboss.org/browse/JBRULES-3141
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Brad Davis
>            Assignee: Mark Proctor
>         Attachments: BasePriorityQueue.java, BinaryHeapPriorityQueueTest.java
>
>
> Attached is a PriorityQueue implementation I wrote last night to replace our home grown implementation.  I think it must have preceded the PriorityBlockingQueue that is already part of Java 5 & 6.
> BinaryHeapPriorityQueueTest is where I plugged in this implementation.  Below are the results first running with our home grown BinaryHeapPriorityQueue, and then with the one I created, BasePriorityQueue.  There are numerous other benefits to using this as well, as it will fully implement the java.util.Collections API and therefore cleanup some other code elsewhere in our codebase.
> The result for 10000 objects inserted and retracted was: 
> BinaryHeapPriortyQueue
> elapsedEnqueue = 32
> elapsedDequeue = 294
> BasePriorityQueue
> elapsedEnqueue = 26
> elapsedDequeue = 167

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 01:25:23 2011
From: jira-events at lists.jboss.org (Brad Davis (JIRA))
Date: Thu, 14 Jul 2011 01:25:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-3141) Replace
 BinaryHeapPriorityQueue Implementation with Java's PriorityBlockingQueue
In-Reply-To: <436055328.52349.1310621003612.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1361119214.52358.1310621123818.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brad Davis updated JBRULES-3141:
--------------------------------

    Attachment: BasePriorityQueue.java
                BinaryHeapPriorityQueueTest.java


> Replace BinaryHeapPriorityQueue Implementation with Java's PriorityBlockingQueue
> --------------------------------------------------------------------------------
>
>                 Key: JBRULES-3141
>                 URL: https://issues.jboss.org/browse/JBRULES-3141
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Brad Davis
>            Assignee: Mark Proctor
>         Attachments: BasePriorityQueue.java, BinaryHeapPriorityQueueTest.java
>
>
> Attached is a PriorityQueue implementation I wrote last night to replace our home grown implementation.  I think it must have preceded the PriorityBlockingQueue that is already part of Java 5 & 6.
> BinaryHeapPriorityQueueTest is where I plugged in this implementation.  Below are the results first running with our home grown BinaryHeapPriorityQueue, and then with the one I created, BasePriorityQueue.  There are numerous other benefits to using this as well, as it will fully implement the java.util.Collections API and therefore cleanup some other code elsewhere in our codebase.
> The result for 10000 objects inserted and retracted was: 
> BinaryHeapPriortyQueue
> elapsedEnqueue = 32
> elapsedDequeue = 294
> BasePriorityQueue
> elapsedEnqueue = 26
> elapsedDequeue = 167

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 02:30:23 2011
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 14 Jul 2011 02:30:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-1345) JDBC_PING fails to
 initialize table in mysql
In-Reply-To: <146558224.51504.1310586863624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <543104996.52625.1310625023795.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban updated JGRP-1345:
---------------------------

         Assignee: Sanne Grinovero  (was: Bela Ban)
    Fix Version/s: 2.12.2
                   3.0


> JDBC_PING fails to initialize table in mysql
> --------------------------------------------
>
>                 Key: JGRP-1345
>                 URL: https://issues.jboss.org/browse/JGRP-1345
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.12
>            Reporter: Ra?l Raja Mart?nez
>            Assignee: Sanne Grinovero
>             Fix For: 2.12.2, 3.0
>
>
> JDBC_PING fails to initialize DB table for discover when executing the following SQL:
> CREATE TABLE JGROUPSPING (own_addr varchar(200) NOT NULL, cluster_name varchar(200) NOT NULL, ping_data varbinary(5000) DEFAULT NULL, PRIMARY KEY (own_addr, cluster_name) )
> The statement results in "Specified key was too long; max key length is 1000 bytes"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Thu Jul 14 02:43:36 2011
From: jira-events at lists.jboss.org (Craig Ringer (JIRA))
Date: Thu, 14 Jul 2011 02:43:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1277) NPE when processing
 web.xml containing a <data-source/> element
Message-ID: <1170288922.52655.1310625816919.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

NPE when processing web.xml containing a <data-source/> element
---------------------------------------------------------------

                 Key: AS7-1277
                 URL: https://issues.jboss.org/browse/AS7-1277
             Project: Application Server 7
          Issue Type: Bug
    Affects Versions: 7.0.0.Final
         Environment: Windows 7 Professional x64 SP1  (also reproduced on Fedora 15 x64 and Ubuntu 11.04 x86)

JBoss AS 7 Final

java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
            Reporter: Craig Ringer


A webapp that uses the standard <data-source/> element to define a datasource within web.xml fails during the post-deploy step with the following backtrace:

14:38:18,717 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) Starting deployment of "dsmap2.war"
14:38:18,741 INFO  [org.jboss.jpa] (MSC service thread 1-6) read persistence.xml for org.example_dsmap2_war_1.0-SNAPSHOTPU
14:38:18,751 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC00001: Failed to start service jboss.deployment.unit."dsmap2.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."dsmap2.war".POST_MODULE: Failed to process phase POST_MODULE of deployment "dsmap2.war"
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
	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_26]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
	at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]
Caused by: java.lang.NullPointerException
	at org.jboss.as.ee.datasource.DataSourceDefinitionDeploymentDescriptorParser.getBindingConfiguration(DataSourceDefinitionDeploymentDescriptorParser.java:101)
	at org.jboss.as.ee.datasource.DataSourceDefinitionDeploymentDescriptorParser.processDescriptorEntries(DataSourceDefinitionDeploymentDescriptorParser.java:58)
	at org.jboss.as.ee.component.AbstractDeploymentDescriptorBindingsProcessor.deploy(AbstractDeploymentDescriptorBindingsProcessor.java:60)
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
	... 5 more


A test case that uses a simple JavaDB database definition is attached. The test case deploys fine on Glassfish 3.1.1.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 02:45:24 2011
From: jira-events at lists.jboss.org (Scott Stark (JIRA))
Date: Thu, 14 Jul 2011 02:45:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1260) JGroups subsystem
 fails to setup some protocol stacks.
In-Reply-To: <1568744513.48245.1310478143759.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <745314880.52660.1310625924081.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Stark commented on AS7-1260:
----------------------------------

Even with the https://github.com/jbossas/jboss-as/commit/2efc0479e040dfabeb8ded9a9e8fde99c6fccbd7 commit to address this, there still was a problem with the ProtocolStackAdd.Protocol.getField method due to the check for whether a super class implemented Protocol being reversed. This getField impl allowed me to setup a stack with bind_addr set across the protocols.

        private static Field getField(Class<?> targetClass, String property) {
            Field field = null;
            try {
                field = targetClass.getDeclaredField(property);
            } catch (NoSuchFieldException e) {
                Class<?> superClass = targetClass.getSuperclass();
                field = (superClass != null) && (org.jgroups.stack.Protocol.class.isAssignableFrom(superClass)) ? getField(superClass, property) : null;
            }
            return field;
        }


> JGroups subsystem fails to setup some protocol stacks.
> ------------------------------------------------------
>
>                 Key: AS7-1260
>                 URL: https://issues.jboss.org/browse/AS7-1260
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.Final
>            Reporter: Trustin Lee
>            Assignee: Paul Ferraro
>            Priority: Critical
>
> After upgrading from AS 7.0.0.CR1 to AS 7.0.0.Final, I started to see an exception raised by org.jboss.as.clustering.jgroups.JChannelFactory:
> {code}
> 22:11:54,040 ERROR [stderr] (MSC service thread 1-1) java.lang.IllegalArgumentException: org.jgroups.ChannelException: unable to setup the protocol stack
> 22:11:54,040 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.ChannelProvider.getJGroupsChannel(ChannelProvider.java:71)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:273)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:226)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:254)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:148)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at java.lang.reflect.Method.invoke(Method.java:597)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:918)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:711)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:611)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:176)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:171)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.CacheImpl.start(CacheImpl.java:366)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:559)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:479)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:84)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:73)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:73)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at java.lang.Thread.run(Thread.java:680)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) Caused by: org.jgroups.ChannelException: unable to setup the protocol stack
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.init(JChannel.java:1728)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.<init>(JChannel.java:249)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.jgroups.JChannelFactory$JChannel.<init>(JChannelFactory.java:269)
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:69)
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.ChannelProvider.getJGroupsChannel(ChannelProvider.java:67)
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	... 26 more
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) Caused by: java.lang.IllegalArgumentException: the following properties in PING are not recognized: {bind_addr=192.168.0.196}
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.createLayer(Configurator.java:460)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.createProtocols(Configurator.java:393)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:88)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:55)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:534)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.init(JChannel.java:1725)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	... 30 more
> {code}
> (Actually, the exception was being swallowed by Infinispan, so I had to modify the source code in Infinispan.)
> Reverting back only the JGroups subsystem to 7.0.0.CR1 fixes the problem for UDP stack.  TCP stack still fails when configuring MPING:
> {code}
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) Caused by: java.lang.IllegalArgumentException: the following properties in MPING are not recognized: {start_port=0}
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.createLayer(Configurator.java:460)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.createProtocols(Configurator.java:393)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:88)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:55)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:534)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.JChannel.init(JChannel.java:1725)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	... 30 more
> {code}
> The offending subsystem configuration is:
> {code}
>         <subsystem xmlns="urn:jboss:domain:jgroups:1.0" default-stack="udp">
>             <stack name="udp">
>                 <transport type="UDP"
>                            socket-binding="jgroups-udp"
>                            default-executor="jgroups"
>                            oob-executor="jgroups-oob"
>                            timer-executor="jgroups-timer"/>
>                 <protocol type="PING"/>
>                 <protocol type="MERGE2"/>
>                 <protocol type="FD_SOCK"/>
>                 <protocol type="FD"/>
>                 <protocol type="VERIFY_SUSPECT"/>
>                 <protocol type="BARRIER"/>
>                 <protocol type="pbcast.NAKACK"/>
>                 <protocol type="UNICAST"/>
>                 <protocol type="pbcast.STABLE"/>
>                 <protocol type="VIEW_SYNC"/>
>                 <protocol type="pbcast.GMS"/>
>                 <protocol type="UFC"/>
>                 <protocol type="MFC"/>
>                 <protocol type="FRAG2"/>
>                 <protocol type="pbcast.STREAMING_STATE_TRANSFER"/>
>                 <protocol type="pbcast.FLUSH"/>
>             </stack>
>             <stack name="tcp">
>                 <transport type="TCP"
>                            socket-binding="jgroups-tcp"
>                            default-executor="jgroups"
>                            oob-executor="jgroups-oob"
>                            timer-executor="jgroups-timer"/>
>                 <protocol type="MPING" socket-binding="jgroups-mping"/>
>                 <protocol type="MERGE2"/>
>                 <protocol type="FD_SOCK"/>
>                 <protocol type="FD"/>
>                 <protocol type="VERIFY_SUSPECT"/>
>                 <protocol type="BARRIER"/>
>                 <protocol type="pbcast.NAKACK"/>
>                 <protocol type="UNICAST"/>
>                 <protocol type="pbcast.STABLE"/>
>                 <protocol type="VIEW_SYNC"/>
>                 <protocol type="pbcast.GMS"/>
>                 <protocol type="UFC"/>
>                 <protocol type="MFC"/>
>                 <protocol type="FRAG2"/>
>                 <protocol type="pbcast.STREAMING_STATE_TRANSFER"/>
>                 <protocol type="pbcast.FLUSH"/>
>             </stack>
>         </subsystem>
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 02:45:24 2011
From: jira-events at lists.jboss.org (Craig Ringer (JIRA))
Date: Thu, 14 Jul 2011 02:45:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1277) NPE when processing
 web.xml containing a <data-source/> element
In-Reply-To: <1170288922.52655.1310625816919.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1678500169.52663.1310625924237.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Craig Ringer updated AS7-1277:
------------------------------

    Attachment: jboss-ds-defn-testcase.zip


A test case that demonstrates how a trivial app fails to deploy on JBoss AS 7 if it uses the <data-source/> element to define a data source using the portable, standard EE 6 mechanism as described in the section "Creating Datasource Definitions Using a Deployment Descriptor" here:

http://blogs.oracle.com/enterprisetechtips/entry/datasource_resource_definition_in_java

This test case deploys fine on Glassfish 3.1.1.

> NPE when processing web.xml containing a <data-source/> element
> ---------------------------------------------------------------
>
>                 Key: AS7-1277
>                 URL: https://issues.jboss.org/browse/AS7-1277
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Final
>         Environment: Windows 7 Professional x64 SP1  (also reproduced on Fedora 15 x64 and Ubuntu 11.04 x86)
> JBoss AS 7 Final
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
>            Reporter: Craig Ringer
>              Labels: data_source, datasource, deployment, persistence, web_xml
>         Attachments: jboss-ds-defn-testcase.zip
>
>
> A webapp that uses the standard <data-source/> element to define a datasource within web.xml fails during the post-deploy step with the following backtrace:
> 14:38:18,717 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) Starting deployment of "dsmap2.war"
> 14:38:18,741 INFO  [org.jboss.jpa] (MSC service thread 1-6) read persistence.xml for org.example_dsmap2_war_1.0-SNAPSHOTPU
> 14:38:18,751 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC00001: Failed to start service jboss.deployment.unit."dsmap2.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."dsmap2.war".POST_MODULE: Failed to process phase POST_MODULE of deployment "dsmap2.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
> 	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_26]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.ee.datasource.DataSourceDefinitionDeploymentDescriptorParser.getBindingConfiguration(DataSourceDefinitionDeploymentDescriptorParser.java:101)
> 	at org.jboss.as.ee.datasource.DataSourceDefinitionDeploymentDescriptorParser.processDescriptorEntries(DataSourceDefinitionDeploymentDescriptorParser.java:58)
> 	at org.jboss.as.ee.component.AbstractDeploymentDescriptorBindingsProcessor.deploy(AbstractDeploymentDescriptorBindingsProcessor.java:60)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
> 	... 5 more
> A test case that uses a simple JavaDB database definition is attached. The test case deploys fine on Glassfish 3.1.1.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 02:47:23 2011
From: jira-events at lists.jboss.org (Craig Ringer (JIRA))
Date: Thu, 14 Jul 2011 02:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-1277) NPE when
 processing web.xml containing a <data-source/> element
In-Reply-To: <1170288922.52655.1310625816919.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <684854981.52666.1310626043638.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Craig Ringer edited comment on AS7-1277 at 7/14/11 2:46 AM:
------------------------------------------------------------

A test case that demonstrates how a trivial app fails to deploy on JBoss AS 7 if it uses the <data-source/> element to define a data source using the portable, standard EE 6 mechanism as described in the section "Creating Datasource Definitions Using a Deployment Descriptor" here:

http://blogs.oracle.com/enterprisetechtips/entry/datasource_resource_definition_in_java

This test case deploys fine on Glassfish 3.1.1.

A non-trivial app that uses a PostgreSQL data source definition (also working on Glassfish) also fails on AS 7. The JDBC driver for Pg is deployed. So this isn't just a JavaDB issue.

      was (Author: ringerc):
    A test case that demonstrates how a trivial app fails to deploy on JBoss AS 7 if it uses the <data-source/> element to define a data source using the portable, standard EE 6 mechanism as described in the section "Creating Datasource Definitions Using a Deployment Descriptor" here:

http://blogs.oracle.com/enterprisetechtips/entry/datasource_resource_definition_in_java

This test case deploys fine on Glassfish 3.1.1.
  
> NPE when processing web.xml containing a <data-source/> element
> ---------------------------------------------------------------
>
>                 Key: AS7-1277
>                 URL: https://issues.jboss.org/browse/AS7-1277
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Final
>         Environment: Windows 7 Professional x64 SP1  (also reproduced on Fedora 15 x64 and Ubuntu 11.04 x86)
> JBoss AS 7 Final
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
>            Reporter: Craig Ringer
>              Labels: data_source, datasource, deployment, persistence, web_xml
>         Attachments: jboss-ds-defn-testcase.zip
>
>
> A webapp that uses the standard <data-source/> element to define a datasource within web.xml fails during the post-deploy step with the following backtrace:
> 14:38:18,717 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) Starting deployment of "dsmap2.war"
> 14:38:18,741 INFO  [org.jboss.jpa] (MSC service thread 1-6) read persistence.xml for org.example_dsmap2_war_1.0-SNAPSHOTPU
> 14:38:18,751 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC00001: Failed to start service jboss.deployment.unit."dsmap2.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."dsmap2.war".POST_MODULE: Failed to process phase POST_MODULE of deployment "dsmap2.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
> 	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_26]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.ee.datasource.DataSourceDefinitionDeploymentDescriptorParser.getBindingConfiguration(DataSourceDefinitionDeploymentDescriptorParser.java:101)
> 	at org.jboss.as.ee.datasource.DataSourceDefinitionDeploymentDescriptorParser.processDescriptorEntries(DataSourceDefinitionDeploymentDescriptorParser.java:58)
> 	at org.jboss.as.ee.component.AbstractDeploymentDescriptorBindingsProcessor.deploy(AbstractDeploymentDescriptorBindingsProcessor.java:60)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
> 	... 5 more
> A test case that uses a simple JavaDB database definition is attached. The test case deploys fine on Glassfish 3.1.1.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 03:00:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Thu, 14 Jul 2011 03:00:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1278) CNFE for module
	javax.mail.api
Message-ID: <661207037.52678.1310626823982.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

CNFE for module javax.mail.api
------------------------------

                 Key: AS7-1278
                 URL: https://issues.jboss.org/browse/AS7-1278
             Project: Application Server 7
          Issue Type: Bug
          Components: Modules
    Affects Versions: 7.0.0.Final
         Environment: 7.1.0.Alpha1 Jenkins build 1402
            Reporter: Juergen Zimmermann
            Assignee: David Lloyd


When I try to send an email via JavaMail I get a CNFE regarding the module "javax.mail.api:main". The missing class javax.net.ssl.SSLPeerUnverifiedException is part of Oracle's JDK in jsse.jar.

Stacktrace:
08:33:31,553 ERROR [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (RMI TCP Connection(11)-127.0.0.1) Failed: de.swe.test.KundenverwaltungTest.createPrivatkunde: javax.ejb.EJBTransactionRolledbackException: Unexpected Error
	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:157)
	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251)
	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.supports(CMTTxInterceptor.java:466)
	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:237)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:47)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
	at de.swe.kundenverwaltung.service.KundenverwaltungListener$$$view138.sendEmail(Unknown Source) [test.jar:]
	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.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
	at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
	at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
	at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:125) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:62) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:125) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
	at de.swe.kundenverwaltung.service.KundenverwaltungListener$Proxy$_$$_Weld$Proxy$.sendEmail(KundenverwaltungListener$Proxy$_$$_Weld$Proxy$.java) [test.jar:]
	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.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
	at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
	at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
	at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
	at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
	at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
	at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
	at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:282) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
	at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:265) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
	at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
	at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:635) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
	at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:628) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
	at org.jboss.weld.event.EventImpl.fire(EventImpl.java:75) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
	at de.swe.kundenverwaltung.service.Kundenverwaltung.createKunde(Kundenverwaltung.java:374) [test.jar:]
	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.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:51)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:114) [jboss-as-weld-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:122) [jboss-as-weld-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
	at de.swe.util.LogInterceptor.log(LogInterceptor.java:81) [test.jar:]
	at sun.reflect.GeneratedMethodAccessor197.invoke(Unknown Source) [: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:66)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:45) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewDescription$ComponentDispatcherInterceptor.processInvocation(ViewDescription.java:202)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:67)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:271)
	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.required(CMTTxInterceptor.java:377)
	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:233)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:47)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
	at de.swe.kundenverwaltung.service.Kundenverwaltung$$$view131.createKunde(Unknown Source) [test.jar:]
	at de.swe.test.KundenverwaltungTest.createPrivatkunde(KundenverwaltungTest.java:262) [test.jar:]
	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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [arquillian-service:]
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [arquillian-service:]
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) [arquillian-service:]
	at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:246) [arquillian-service:]
	at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) [arquillian-service:]
	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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) [arquillian-service:]
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) [arquillian-service:]
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134) [arquillian-service:]
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114) [arquillian-service:]
	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) [arquillian-service:]
	at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38) [arquillian-service:]
	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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) [arquillian-service:]
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) [arquillian-service:]
	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:82) [arquillian-service:]
	at sun.reflect.GeneratedMethodAccessor199.invoke(Unknown Source) [: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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) [arquillian-service:]
	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:68) [arquillian-service:]
	at sun.reflect.GeneratedMethodAccessor196.invoke(Unknown Source) [: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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) [arquillian-service:]
	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:54) [arquillian-service:]
	at sun.reflect.GeneratedMethodAccessor195.invoke(Unknown Source) [: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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) [arquillian-service:]
	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134) [arquillian-service:]
	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) [arquillian-service:]
	at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:239) [arquillian-service:]
	at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:202) [arquillian-service:]
	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:290) [arquillian-service:]
	at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:45) [arquillian-service:]
	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:216) [arquillian-service:]
	at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110) [arquillian-service:]
	at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79) [arquillian-service:]
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71) [arquillian-service:]
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49) [arquillian-service:]
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) [arquillian-service:]
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) [arquillian-service:]
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) [arquillian-service:]
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) [arquillian-service:]
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) [arquillian-service:]
	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:161) [arquillian-service:]
	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:290) [arquillian-service:]
	at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:45) [arquillian-service:]
	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:175) [arquillian-service:]
	at org.junit.runners.ParentRunner.run(ParentRunner.java:236) [arquillian-service:]
	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:123) [arquillian-service:]
	at org.junit.runner.JUnitCore.run(JUnitCore.java:157) [arquillian-service:]
	at org.junit.runner.JUnitCore.run(JUnitCore.java:136) [arquillian-service:]
	at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:65) [arquillian-service:]
	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:152) [arquillian-service:]
	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodRemote(JMXTestRunner.java:112) [arquillian-service:]
	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethodRemote(ArquillianService.java:205) [arquillian-service:]
	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 com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93) [:1.6.0_26]
	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27) [:1.6.0_26]
	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208) [:1.6.0_26]
	at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120) [:1.6.0_26]
	at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262) [:1.6.0_26]
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836) [:1.6.0_26]
	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761) [:1.6.0_26]
	at org.jboss.as.jmx.tcl.TcclMBeanServer.invoke(TcclMBeanServer.java:214)
	at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427) [:1.6.0_26]
	at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72) [:1.6.0_26]
	at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265) [:1.6.0_26]
	at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360) [:1.6.0_26]
	at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788) [:1.6.0_26]
	at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source) [: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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) [:1.6.0_26]
	at sun.rmi.transport.Transport$1.run(Transport.java:159) [:1.6.0_26]
	at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_26]
	at sun.rmi.transport.Transport.serviceCall(Transport.java:155) [:1.6.0_26]
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) [:1.6.0_26]
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) [:1.6.0_26]
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) [:1.6.0_26]
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
	at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]
Caused by: java.lang.NoClassDefFoundError: javax/net/ssl/SSLPeerUnverifiedException
	at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1900) [mail-1.4.4.jar:1.4.4]
	at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:638) [mail-1.4.4.jar:1.4.4]
	at javax.mail.Service.connect(Service.java:317) [mail-1.4.4.jar:1.4.4]
	at javax.mail.Service.connect(Service.java:176) [mail-1.4.4.jar:1.4.4]
	at javax.mail.Service.connect(Service.java:125) [mail-1.4.4.jar:1.4.4]
	at javax.mail.Transport.send0(Transport.java:194) [mail-1.4.4.jar:1.4.4]
	at javax.mail.Transport.send(Transport.java:124) [mail-1.4.4.jar:1.4.4]
	at de.swe.kundenverwaltung.service.KundenverwaltungListener.sendEmail(KundenverwaltungListener.java:74) [test.jar:]
	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.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:51)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:114) [jboss-as-weld-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:122) [jboss-as-weld-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
	at de.swe.util.LogInterceptor.log(LogInterceptor.java:81) [test.jar:]
	at sun.reflect.GeneratedMethodAccessor197.invoke(Unknown Source) [: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:66)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:45) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewDescription$ComponentDispatcherInterceptor.processInvocation(ViewDescription.java:202)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:67)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:247)
	... 190 more
Caused by: java.lang.ClassNotFoundException: javax.net.ssl.SSLPeerUnverifiedException from [Module "javax.mail.api:main" from local module loader @a6d51e (roots: C:\Software\jboss-7.1.0.Alpha1-b1402\modules)]
	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191) [jboss-modules.jar:1.0.1.GA]
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358) [jboss-modules.jar:1.0.1.GA]
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330) [jboss-modules.jar:1.0.1.GA]
	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307) [jboss-modules.jar:1.0.1.GA]
	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101) [jboss-modules.jar:1.0.1.GA]
	... 234 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 03:41:24 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Thu, 14 Jul 2011 03:41:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1258) required
 xa-data-source-properties is missing from add operation description
In-Reply-To: <1892072371.48008.1310473583620.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <934518911.52755.1310629284033.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefano Maestri reassigned AS7-1258:
------------------------------------

    Assignee: Jeff Zhang  (was: Stefano Maestri)


> required xa-data-source-properties is missing from add operation description
> ----------------------------------------------------------------------------
>
>                 Key: AS7-1258
>                 URL: https://issues.jboss.org/browse/AS7-1258
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 7.0.0.CR1
>            Reporter: Alexey Loubyansky
>            Assignee: Jeff Zhang
>
> xa-data-source-properties property is required by add operation but is missing from the operation description.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 03:41:24 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Thu, 14 Jul 2011 03:41:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1212)
 :read-operation-description(name=add) shows pool-name as optional,
 but deploy without pool-name fail
In-Reply-To: <2010325607.37641.1309966343681.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1207068456.52759.1310629284243.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefano Maestri reassigned AS7-1212:
------------------------------------

    Assignee: Jeff Zhang  (was: Stefano Maestri)


> :read-operation-description(name=add) shows pool-name as optional, but deploy without pool-name fail
> ----------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1212
>                 URL: https://issues.jboss.org/browse/AS7-1212
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management, JCA
>    Affects Versions: 7.0.0.CR1
>            Reporter: Heiko Rupp
>            Assignee: Jeff Zhang
>
> [domain at localhost:9999 subsystem=datasources] ./data-source=java\:jboss\/datasources\/ExampleDS:read-operation-description(name=add)
> {
>     "outcome" => "success",
>     "result" => {
>         "operation-name" => "add",
>         "description" => "Adds a new data-source",
>         "request-properties" => {
> ....
>        "pool-name" => {
>                 "description" => "Specifies the pool name for the datasource used for management",
>                 "type" => STRING,
>                 "required" => false
>             },
> So the pool-name is optional, but when I deploy a data source without pool name, deployment fails: 
> [Server:server-one] 17:26:49,124 ERROR [stderr] (pool-1-thread-42) org.jboss.jca.common.api.validator.ValidateException: IJ010068: Missing required attribute pool-name in org.jboss.jca.common.metadata.ds.DataSourceImpl

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 03:51:23 2011
From: jira-events at lists.jboss.org (Takayoshi Kimura (JIRA))
Date: Thu, 14 Jul 2011 03:51:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1277) NPE when processing
 web.xml containing a <data-source/> element
In-Reply-To: <1170288922.52655.1310625816919.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <71194137.52780.1310629883693.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Takayoshi Kimura commented on AS7-1277:
---------------------------------------

Looks like we don't handle optional attributes (description and isolation-level) properly.

> NPE when processing web.xml containing a <data-source/> element
> ---------------------------------------------------------------
>
>                 Key: AS7-1277
>                 URL: https://issues.jboss.org/browse/AS7-1277
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Final
>         Environment: Windows 7 Professional x64 SP1  (also reproduced on Fedora 15 x64 and Ubuntu 11.04 x86)
> JBoss AS 7 Final
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
>            Reporter: Craig Ringer
>              Labels: data_source, datasource, deployment, persistence, web_xml
>         Attachments: jboss-ds-defn-testcase.zip
>
>
> A webapp that uses the standard <data-source/> element to define a datasource within web.xml fails during the post-deploy step with the following backtrace:
> 14:38:18,717 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) Starting deployment of "dsmap2.war"
> 14:38:18,741 INFO  [org.jboss.jpa] (MSC service thread 1-6) read persistence.xml for org.example_dsmap2_war_1.0-SNAPSHOTPU
> 14:38:18,751 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC00001: Failed to start service jboss.deployment.unit."dsmap2.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."dsmap2.war".POST_MODULE: Failed to process phase POST_MODULE of deployment "dsmap2.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
> 	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_26]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.ee.datasource.DataSourceDefinitionDeploymentDescriptorParser.getBindingConfiguration(DataSourceDefinitionDeploymentDescriptorParser.java:101)
> 	at org.jboss.as.ee.datasource.DataSourceDefinitionDeploymentDescriptorParser.processDescriptorEntries(DataSourceDefinitionDeploymentDescriptorParser.java:58)
> 	at org.jboss.as.ee.component.AbstractDeploymentDescriptorBindingsProcessor.deploy(AbstractDeploymentDescriptorBindingsProcessor.java:60)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
> 	... 5 more
> A test case that uses a simple JavaDB database definition is attached. The test case deploys fine on Glassfish 3.1.1.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 04:09:24 2011
From: jira-events at lists.jboss.org (Sanne Grinovero (JIRA))
Date: Thu, 14 Jul 2011 04:09:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1345) JDBC_PING fails to
 initialize table in mysql
In-Reply-To: <146558224.51504.1310586863624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <744634710.52842.1310630964018.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Sanne Grinovero commented on JGRP-1345:
---------------------------------------

Hi Ra?l,
what is the important difference between the two statements? It looks like you only selected the ENGINE and charset options, but that are non-standard options of MySQL; also you're using "IF NOT EXISTS", which is alas non standard as well, and while it is a nice to have, it's not needed as JGroups won't fail if the table creation fails - assuming it failed because the table already existed.

The default SQL statement is using standard SQL only on purpose: I can't change that or it will break all other databases.
I had tested it on MySQL but I was using InnoDB as default engine, also I have the habit to always use those utf8 charsets and collations (specified in the global configuration file of the database server and client).

I think it's very likely that people will have to customize the SQL statements for each case, so I'm not considering this as a bug as the default configuration doesn't work on MySQL, but it works fine when configured properly.

What do you suggest I could do to clarify this or make it easier? I'll add your SQL initialization to the WIKI page of JDBC_PING.

> JDBC_PING fails to initialize table in mysql
> --------------------------------------------
>
>                 Key: JGRP-1345
>                 URL: https://issues.jboss.org/browse/JGRP-1345
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.12
>            Reporter: Ra?l Raja Mart?nez
>            Assignee: Sanne Grinovero
>             Fix For: 2.12.2, 3.0
>
>
> JDBC_PING fails to initialize DB table for discover when executing the following SQL:
> CREATE TABLE JGROUPSPING (own_addr varchar(200) NOT NULL, cluster_name varchar(200) NOT NULL, ping_data varbinary(5000) DEFAULT NULL, PRIMARY KEY (own_addr, cluster_name) )
> The statement results in "Specified key was too long; max key length is 1000 bytes"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Thu Jul 14 04:22:23 2011
From: jira-events at lists.jboss.org (Sanne Grinovero (JIRA))
Date: Thu, 14 Jul 2011 04:22:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1345) JDBC_PING fails to
 initialize table in mysql
In-Reply-To: <146558224.51504.1310586863624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1859277450.52914.1310631743756.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Sanne Grinovero commented on JGRP-1345:
---------------------------------------

I've updated this with your settings: http://community.jboss.org/wiki/JDBCPING
And I'm going to mark this as "won't solve", still if you have suggestions about how to improve user experience with this I'll be glad to hear about it; we could make a custom extension "MYSQL_PING" which hardcodes all what's needed for MySQL, or have an ENUM like parameter which selects SQL statements among a set of tested configurations.

> JDBC_PING fails to initialize table in mysql
> --------------------------------------------
>
>                 Key: JGRP-1345
>                 URL: https://issues.jboss.org/browse/JGRP-1345
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.12
>            Reporter: Ra?l Raja Mart?nez
>            Assignee: Sanne Grinovero
>             Fix For: 2.12.2, 3.0
>
>
> JDBC_PING fails to initialize DB table for discover when executing the following SQL:
> CREATE TABLE JGROUPSPING (own_addr varchar(200) NOT NULL, cluster_name varchar(200) NOT NULL, ping_data varbinary(5000) DEFAULT NULL, PRIMARY KEY (own_addr, cluster_name) )
> The statement results in "Specified key was too long; max key length is 1000 bytes"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Thu Jul 14 04:24:23 2011
From: jira-events at lists.jboss.org (Sanne Grinovero (JIRA))
Date: Thu, 14 Jul 2011 04:24:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (JGRP-1345)
 JDBC_PING fails to initialize table in mysql
In-Reply-To: <146558224.51504.1310586863624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <319389797.52918.1310631863700.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Sanne Grinovero edited comment on JGRP-1345 at 7/14/11 4:22 AM:
----------------------------------------------------------------

I've updated this with your settings: http://community.jboss.org/wiki/JDBCPING
And I'm going to mark this as "won't solve" as it's not a bug, still I agree it could be easier to get started. If you have suggestions about how to improve user experience with this I'll be glad to hear about it; we could make a custom extension "MYSQL_PING" which hardcodes all what's needed for MySQL, or have an ENUM like parameter which selects SQL statements among a set of tested configurations.

      was (Author: sannegrinovero):
    I've updated this with your settings: http://community.jboss.org/wiki/JDBCPING
And I'm going to mark this as "won't solve", still if you have suggestions about how to improve user experience with this I'll be glad to hear about it; we could make a custom extension "MYSQL_PING" which hardcodes all what's needed for MySQL, or have an ENUM like parameter which selects SQL statements among a set of tested configurations.
  
> JDBC_PING fails to initialize table in mysql
> --------------------------------------------
>
>                 Key: JGRP-1345
>                 URL: https://issues.jboss.org/browse/JGRP-1345
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.12
>            Reporter: Ra?l Raja Mart?nez
>            Assignee: Sanne Grinovero
>             Fix For: 2.12.2, 3.0
>
>
> JDBC_PING fails to initialize DB table for discover when executing the following SQL:
> CREATE TABLE JGROUPSPING (own_addr varchar(200) NOT NULL, cluster_name varchar(200) NOT NULL, ping_data varbinary(5000) DEFAULT NULL, PRIMARY KEY (own_addr, cluster_name) )
> The statement results in "Specified key was too long; max key length is 1000 bytes"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Thu Jul 14 04:26:23 2011
From: jira-events at lists.jboss.org (Sanne Grinovero (JIRA))
Date: Thu, 14 Jul 2011 04:26:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JGRP-1345) JDBC_PING fails to
 initialize table in mysql
In-Reply-To: <146558224.51504.1310586863624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <725732948.52926.1310631983709.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Sanne Grinovero closed JGRP-1345.
---------------------------------

    Resolution: Rejected


As explained in the comments, it's not a bug but using a wrong database configuration.

> JDBC_PING fails to initialize table in mysql
> --------------------------------------------
>
>                 Key: JGRP-1345
>                 URL: https://issues.jboss.org/browse/JGRP-1345
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.12
>            Reporter: Ra?l Raja Mart?nez
>            Assignee: Sanne Grinovero
>             Fix For: 2.12.2, 3.0
>
>
> JDBC_PING fails to initialize DB table for discover when executing the following SQL:
> CREATE TABLE JGROUPSPING (own_addr varchar(200) NOT NULL, cluster_name varchar(200) NOT NULL, ping_data varbinary(5000) DEFAULT NULL, PRIMARY KEY (own_addr, cluster_name) )
> The statement results in "Specified key was too long; max key length is 1000 bytes"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Thu Jul 14 04:33:23 2011
From: jira-events at lists.jboss.org (Craig Ringer (JIRA))
Date: Thu, 14 Jul 2011 04:33:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1277) NPE when processing
 web.xml containing a <data-source/> element
In-Reply-To: <1170288922.52655.1310625816919.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1818826694.52964.1310632403939.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Craig Ringer commented on AS7-1277:
-----------------------------------

Yep, that looks like it. Adding:

        <description>blah</description>
        <isolation-level>TRANSACTION_READ_COMMITTED</isolation-level>

avoids the NPE. So that's a workaround for others hit by this.

Thanks for checking it out! I was still cloning the JBoss sources from git when you replied.

> NPE when processing web.xml containing a <data-source/> element
> ---------------------------------------------------------------
>
>                 Key: AS7-1277
>                 URL: https://issues.jboss.org/browse/AS7-1277
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Final
>         Environment: Windows 7 Professional x64 SP1  (also reproduced on Fedora 15 x64 and Ubuntu 11.04 x86)
> JBoss AS 7 Final
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
>            Reporter: Craig Ringer
>              Labels: data_source, datasource, deployment, persistence, web_xml
>         Attachments: jboss-ds-defn-testcase.zip
>
>
> A webapp that uses the standard <data-source/> element to define a datasource within web.xml fails during the post-deploy step with the following backtrace:
> 14:38:18,717 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) Starting deployment of "dsmap2.war"
> 14:38:18,741 INFO  [org.jboss.jpa] (MSC service thread 1-6) read persistence.xml for org.example_dsmap2_war_1.0-SNAPSHOTPU
> 14:38:18,751 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC00001: Failed to start service jboss.deployment.unit."dsmap2.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."dsmap2.war".POST_MODULE: Failed to process phase POST_MODULE of deployment "dsmap2.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
> 	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_26]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.ee.datasource.DataSourceDefinitionDeploymentDescriptorParser.getBindingConfiguration(DataSourceDefinitionDeploymentDescriptorParser.java:101)
> 	at org.jboss.as.ee.datasource.DataSourceDefinitionDeploymentDescriptorParser.processDescriptorEntries(DataSourceDefinitionDeploymentDescriptorParser.java:58)
> 	at org.jboss.as.ee.component.AbstractDeploymentDescriptorBindingsProcessor.deploy(AbstractDeploymentDescriptorBindingsProcessor.java:60)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
> 	... 5 more
> A test case that uses a simple JavaDB database definition is attached. The test case deploys fine on Glassfish 3.1.1.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 04:42:24 2011
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 14 Jul 2011 04:42:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1279) Operation to delete
 all config file snapshots
Message-ID: <1067842761.52990.1310632944982.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Operation to delete all config file snapshots
---------------------------------------------

                 Key: AS7-1279
                 URL: https://issues.jboss.org/browse/AS7-1279
             Project: Application Server 7
          Issue Type: Feature Request
            Reporter: Kabir Khan
            Assignee: Kabir Khan
             Fix For: 7.0.1.Final


Hi,

I was wondering using CLI (jboss-admin), can I blow away all the 
snapshots? I see only one operation : delete-snapshot which requires the 
"uniquely" identifiable snapshot name.


Thx

Vimal

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 04:46:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 14 Jul 2011 04:46:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1280) WebComponentProcessor
 tries to create component out of empty classname
Message-ID: <329314507.52998.1310633184234.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

WebComponentProcessor tries to create component out of empty classname
----------------------------------------------------------------------

                 Key: AS7-1280
                 URL: https://issues.jboss.org/browse/AS7-1280
             Project: Application Server 7
          Issue Type: Bug
          Components: EE
    Affects Versions: 7.0.0.Final
            Reporter: jaikiran pai
            Assignee: jaikiran pai


A user reported error:

{code}
02:06:05,229 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) 
MSC00001: Failed to start service jboss.deployment.unit."projvehimerc.war".
PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."projvehimerc.war".
PARSE: Failed to process phase PARSE of deployment "projvehimerc.war"
          at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
          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_25]
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_25]
          at java.lang.Thread.run(Thread.java:662) [:1.6.0_25]
Caused by: java.lang.IllegalArgumentException: Empty name segment is not allowed
          at org.jboss.msc.service.ServiceName.of(ServiceName.java:85)
          at org.jboss.msc.service.ServiceName.append(ServiceName.java:112)
          at org.jboss.as.ee.component.ComponentDescription.<init>(ComponentDescription.java:145)
          at org.jboss.as.web.deployment.component.WebComponentDescription.<init>(WebComponentDescription.java:37)
          at org.jboss.as.web.deployment.component.WebComponentProcessor.deploy(WebComponentProcessor.java:126)
          at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
          ... 5 more
{code}

Please see the referenced forum thread for details.
 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 05:07:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 14 Jul 2011 05:07:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1277) NPE when processing
 web.xml containing a <data-source/> element
In-Reply-To: <1170288922.52655.1310625816919.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1243479706.53037.1310634443664.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai reassigned AS7-1277:
---------------------------------

    Assignee: jaikiran pai


> NPE when processing web.xml containing a <data-source/> element
> ---------------------------------------------------------------
>
>                 Key: AS7-1277
>                 URL: https://issues.jboss.org/browse/AS7-1277
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Final
>         Environment: Windows 7 Professional x64 SP1  (also reproduced on Fedora 15 x64 and Ubuntu 11.04 x86)
> JBoss AS 7 Final
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
>            Reporter: Craig Ringer
>            Assignee: jaikiran pai
>              Labels: data_source, datasource, deployment, persistence, web_xml
>         Attachments: jboss-ds-defn-testcase.zip
>
>
> A webapp that uses the standard <data-source/> element to define a datasource within web.xml fails during the post-deploy step with the following backtrace:
> 14:38:18,717 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) Starting deployment of "dsmap2.war"
> 14:38:18,741 INFO  [org.jboss.jpa] (MSC service thread 1-6) read persistence.xml for org.example_dsmap2_war_1.0-SNAPSHOTPU
> 14:38:18,751 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC00001: Failed to start service jboss.deployment.unit."dsmap2.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."dsmap2.war".POST_MODULE: Failed to process phase POST_MODULE of deployment "dsmap2.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
> 	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_26]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.ee.datasource.DataSourceDefinitionDeploymentDescriptorParser.getBindingConfiguration(DataSourceDefinitionDeploymentDescriptorParser.java:101)
> 	at org.jboss.as.ee.datasource.DataSourceDefinitionDeploymentDescriptorParser.processDescriptorEntries(DataSourceDefinitionDeploymentDescriptorParser.java:58)
> 	at org.jboss.as.ee.component.AbstractDeploymentDescriptorBindingsProcessor.deploy(AbstractDeploymentDescriptorBindingsProcessor.java:60)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
> 	... 5 more
> A test case that uses a simple JavaDB database definition is attached. The test case deploys fine on Glassfish 3.1.1.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 05:13:24 2011
From: jira-events at lists.jboss.org (=?UTF-8?Q?Juri_Timo=C5=A1in_=28JIRA=29?=)
Date: Thu, 14 Jul 2011 05:13:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1281) Cannot deploy
 different EARs with same WARs inside.
Message-ID: <1792558469.53067.1310634804225.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Cannot deploy different EARs with same WARs inside.
---------------------------------------------------

                 Key: AS7-1281
                 URL: https://issues.jboss.org/browse/AS7-1281
             Project: Application Server 7
          Issue Type: Bug
          Components: EJB
    Affects Versions: 7.0.0.Final
         Environment: $uname -a
Linux 2.6.38-10-generic-pae #46-Ubuntu SMP Tue Jun 28 16:54:49 UTC 2011 i686 i686 i386 GNU/Linux

            Reporter: Juri Timo?in
            Assignee: Carlo de Wolf


Hello, I have a problem of deploying several EARs on jboss-as-7.0.0-Final.
 
I have 2 EARs, both have test.war inside them. I cannot deploy both EARs at the same time
 
10:09:31,237 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.subunit."myTest.ear"."test.war".INSTALL: org.jboss.msc.
service.StartException in service jboss.deployment.subunit."myTest.ear"."test.war".INSTALL: Failed to process phase INSTALL of subdeployment "test.war" of deployment "myTest.ear"
        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
        at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
        at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to add JBoss web deployment service
        at org.jboss.as.web.deployment.WarDeploymentProcessor.processDeployment(WarDeploymentProcessor.java:234)
        at org.jboss.as.web.deployment.WarDeploymentProcessor.deploy(WarDeploymentProcessor.java:105)
        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
        ... 5 more
Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.web.realm."test.war" is already registered
        at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:154)
        at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:226)
        at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:560)
        at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201)
        at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2194)
        at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201)
        at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2194)
        at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:307)
        at org.jboss.as.web.deployment.WarDeploymentProcessor.processDeployment(WarDeploymentProcessor.java:209)
        ... 7 more
 
If I deploy them 1 by 1 then only the first one deploys. If i deploy them both at the same time, then both deployments are rolled back.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Thu Jul 14 05:15:24 2011
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Thu, 14 Jul 2011 05:15:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1281) Cannot deploy
 different EARs with same WARs inside.
In-Reply-To: <1792558469.53067.1310634804225.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <907685344.53083.1310634924363.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

SBS JIRA Integration updated AS7-1281:
--------------------------------------

    Forum Reference: http://community.jboss.org/message/615120#615120, http://community.jboss.org/thread/169402?tstart=0  (was: http://community.jboss.org/thread/169402?tstart=0)


> Cannot deploy different EARs with same WARs inside.
> ---------------------------------------------------
>
>                 Key: AS7-1281
>                 URL: https://issues.jboss.org/browse/AS7-1281
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 7.0.0.Final
>         Environment: $uname -a
> Linux 2.6.38-10-generic-pae #46-Ubuntu SMP Tue Jun 28 16:54:49 UTC 2011 i686 i686 i386 GNU/Linux
>            Reporter: Juri Timo?in
>            Assignee: Carlo de Wolf
>              Labels: deploy, duplicate-service-exception, ear, ejb, war
>
> Hello, I have a problem of deploying several EARs on jboss-as-7.0.0-Final.
>  
> I have 2 EARs, both have test.war inside them. I cannot deploy both EARs at the same time
>  
> 10:09:31,237 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.subunit."myTest.ear"."test.war".INSTALL: org.jboss.msc.
> service.StartException in service jboss.deployment.subunit."myTest.ear"."test.war".INSTALL: Failed to process phase INSTALL of subdeployment "test.war" of deployment "myTest.ear"
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
>         at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
>         at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to add JBoss web deployment service
>         at org.jboss.as.web.deployment.WarDeploymentProcessor.processDeployment(WarDeploymentProcessor.java:234)
>         at org.jboss.as.web.deployment.WarDeploymentProcessor.deploy(WarDeploymentProcessor.java:105)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
>         ... 5 more
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.web.realm."test.war" is already registered
>         at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:154)
>         at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:226)
>         at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:560)
>         at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201)
>         at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2194)
>         at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201)
>         at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2194)
>         at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:307)
>         at org.jboss.as.web.deployment.WarDeploymentProcessor.processDeployment(WarDeploymentProcessor.java:209)
>         ... 7 more
>  
> If I deploy them 1 by 1 then only the first one deploys. If i deploy them both at the same time, then both deployments are rolled back.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Thu Jul 14 05:33:23 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 14 Jul 2011 05:33:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMESSAGING-1887) Messages
 lost during orderly shutdown of JBoss Messaging server
In-Reply-To: <1202846556.50102.1310553143712.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1683444564.53181.1310636003786.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao resolved JBMESSAGING-1887.
---------------------------------------

    Resolution: Done


> Messages lost during orderly shutdown of JBoss Messaging server
> ---------------------------------------------------------------
>
>                 Key: JBMESSAGING-1887
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1887
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP13, 1.4.7.GA, 1.4.8.SP1
>         Environment: JBoss EAP 5.1.0
>            Reporter: Tom Ross
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP14, 1.4.8.SP2
>
>
> During orderly shutdown of JBoss EAP server/Messaging server messages are being lost.  
> In the above test case a publisher is publishing messages to a topic (which has several durable subscribers) on a JBM server while the user uses control-c to shutdown the server or runs shutdown.sh script.
> The server will first shutdown the topic service (subscribers) and then the server peer and post office. When the subscribers has been just shutdown but the server peer and post office is still alive, if a message are sent in to the post office and post office tries to route the message to subscribers, the subscribers are already deactivated so it didn't get route.
> In this case the post office does not throw any exceptions back to the publisher. Instead it returns without error.
> Following message will apear in the log file:
> (WorkerThread#1[192.168.1.110:56860]) Queue[37225610/2/2952-guest.mdbOne] is not active, returning null delivery for Reference[41396777574629398]:RELIABLE

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 05:33:23 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 14 Jul 2011 05:33:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1887) Messages lost
 during orderly shutdown of JBoss Messaging server
In-Reply-To: <1202846556.50102.1310553143712.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1965336441.53187.1310636003938.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao closed JBMESSAGING-1887.
-------------------------------------



> Messages lost during orderly shutdown of JBoss Messaging server
> ---------------------------------------------------------------
>
>                 Key: JBMESSAGING-1887
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1887
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP13, 1.4.7.GA, 1.4.8.SP1
>         Environment: JBoss EAP 5.1.0
>            Reporter: Tom Ross
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP14, 1.4.8.SP2
>
>
> During orderly shutdown of JBoss EAP server/Messaging server messages are being lost.  
> In the above test case a publisher is publishing messages to a topic (which has several durable subscribers) on a JBM server while the user uses control-c to shutdown the server or runs shutdown.sh script.
> The server will first shutdown the topic service (subscribers) and then the server peer and post office. When the subscribers has been just shutdown but the server peer and post office is still alive, if a message are sent in to the post office and post office tries to route the message to subscribers, the subscribers are already deactivated so it didn't get route.
> In this case the post office does not throw any exceptions back to the publisher. Instead it returns without error.
> Following message will apear in the log file:
> (WorkerThread#1[192.168.1.110:56860]) Queue[37225610/2/2952-guest.mdbOne] is not active, returning null delivery for Reference[41396777574629398]:RELIABLE

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 05:57:24 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 14 Jul 2011 05:57:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-579) Implement JMS MDB
	integration
In-Reply-To: <373845573.30344.1300298446712.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1221720455.53291.1310637444274.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf updated AS7-579:
------------------------------

    Git Pull Request: https://github.com/wolfc/jboss-as/tree/AS7-579


> Implement JMS MDB integration
> -----------------------------
>
>                 Key: AS7-579
>                 URL: https://issues.jboss.org/browse/AS7-579
>             Project: Application Server 7
>          Issue Type: Sub-task
>            Reporter: David Lloyd
>            Assignee: Carlo de Wolf
>            Priority: Critical
>             Fix For: 7.1.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 05:57:24 2011
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Thu, 14 Jul 2011 05:57:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-579) Implement JMS MDB
	integration
In-Reply-To: <373845573.30344.1300298446712.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <884663215.53294.1310637444366.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

SBS JIRA Integration updated AS7-579:
-------------------------------------

    Git Pull Request: https://github.com/wolfc/jboss-as/tree/AS7-579  (was: https://github.com/wolfc/jboss-as/tree/AS7-579)
     Forum Reference: http://community.jboss.org/message/614468#614468


> Implement JMS MDB integration
> -----------------------------
>
>                 Key: AS7-579
>                 URL: https://issues.jboss.org/browse/AS7-579
>             Project: Application Server 7
>          Issue Type: Sub-task
>            Reporter: David Lloyd
>            Assignee: Carlo de Wolf
>            Priority: Critical
>             Fix For: 7.1.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 06:22:23 2011
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Thu, 14 Jul 2011 06:22:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-493) Integrate
 hornetq-ra.rar into AS 7
In-Reply-To: <1342826652.46712.1300887893374.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1871976535.53336.1310638943790.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Andy Taylor commented on AS7-493:
---------------------------------

Carlo, is this an issue in the HornetQ integration or the Jacamar integration or elsewhere?

> Integrate hornetq-ra.rar into AS 7
> ----------------------------------
>
>                 Key: AS7-493
>                 URL: https://issues.jboss.org/browse/AS7-493
>             Project: Application Server 7
>          Issue Type: Task
>          Components: JMS
>            Reporter: Carlo de Wolf
>            Assignee: Andy Taylor
>             Fix For: 7.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 06:26:23 2011
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 14 Jul 2011 06:26:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1345) JDBC_PING fails to
 initialize table in mysql
In-Reply-To: <146558224.51504.1310586863624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <291959245.53344.1310639183694.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1345:
--------------------------------

Raul, maybe a discussion on the JGroups mailing list is preferable before opening a JIRA, next time. We're usually very helpful, and most of the times you get an answer for your questions there !
Cheers,

> JDBC_PING fails to initialize table in mysql
> --------------------------------------------
>
>                 Key: JGRP-1345
>                 URL: https://issues.jboss.org/browse/JGRP-1345
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.12
>            Reporter: Ra?l Raja Mart?nez
>            Assignee: Sanne Grinovero
>             Fix For: 2.12.2, 3.0
>
>
> JDBC_PING fails to initialize DB table for discover when executing the following SQL:
> CREATE TABLE JGROUPSPING (own_addr varchar(200) NOT NULL, cluster_name varchar(200) NOT NULL, ping_data varbinary(5000) DEFAULT NULL, PRIMARY KEY (own_addr, cluster_name) )
> The statement results in "Specified key was too long; max key length is 1000 bytes"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Thu Jul 14 07:18:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 14 Jul 2011 07:18:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1282) Rar classes are not
 made available to deployments
Message-ID: <506537509.53413.1310642303654.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Rar classes are not made available to deployments
-------------------------------------------------

                 Key: AS7-1282
                 URL: https://issues.jboss.org/browse/AS7-1282
             Project: Application Server 7
          Issue Type: Bug
            Reporter: Carlo de Wolf


The rar classes are not made available to a deployment.

{noformat}
java.lang.ClassNotFoundException: org.hornetq.ra.inflow.HornetQActivationSpec from [Module "deployment.ejb3mdb.jar:main" from Service Module Loader]
	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
{noformat}

JCA 1.6 20.3 Class Loading Requirements
{quote}
If a standalone resource adapter is configured to deliver messages to a message-
driven bean in an application, the standalone resource adapter must be made
available to the application.
{quote}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 07:18:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 14 Jul 2011 07:18:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1282) Rar classes are not
 made available to deployments
In-Reply-To: <506537509.53413.1310642303654.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <144338321.53415.1310642303696.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf updated AS7-1282:
-------------------------------

    Fix Version/s: 7.1.0.CR1
         Priority: Critical  (was: Major)
      Component/s: JCA


> Rar classes are not made available to deployments
> -------------------------------------------------
>
>                 Key: AS7-1282
>                 URL: https://issues.jboss.org/browse/AS7-1282
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Carlo de Wolf
>            Priority: Critical
>             Fix For: 7.1.0.CR1
>
>
> The rar classes are not made available to a deployment.
> {noformat}
> java.lang.ClassNotFoundException: org.hornetq.ra.inflow.HornetQActivationSpec from [Module "deployment.ejb3mdb.jar:main" from Service Module Loader]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> {noformat}
> JCA 1.6 20.3 Class Loading Requirements
> {quote}
> If a standalone resource adapter is configured to deliver messages to a message-
> driven bean in an application, the standalone resource adapter must be made
> available to the application.
> {quote}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 07:20:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 14 Jul 2011 07:20:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-493) Integrate
 hornetq-ra.rar into AS 7
In-Reply-To: <1342826652.46712.1300887893374.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1967488553.53420.1310642423746.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf commented on AS7-493:
-----------------------------------

It's more an EJB-JCA integration issue.
I've opened up AS7-1282 instead.

> Integrate hornetq-ra.rar into AS 7
> ----------------------------------
>
>                 Key: AS7-493
>                 URL: https://issues.jboss.org/browse/AS7-493
>             Project: Application Server 7
>          Issue Type: Task
>          Components: JMS
>            Reporter: Carlo de Wolf
>            Assignee: Andy Taylor
>             Fix For: 7.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 07:20:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Thu, 14 Jul 2011 07:20:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-493) Integrate
	hornetq-ra.rar into AS 7
In-Reply-To: <1342826652.46712.1300887893374.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <122756620.53427.1310642423902.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf closed AS7-493.
-----------------------------

    Resolution: Done


> Integrate hornetq-ra.rar into AS 7
> ----------------------------------
>
>                 Key: AS7-493
>                 URL: https://issues.jboss.org/browse/AS7-493
>             Project: Application Server 7
>          Issue Type: Task
>          Components: JMS
>            Reporter: Carlo de Wolf
>            Assignee: Andy Taylor
>             Fix For: 7.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 08:13:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 14 Jul 2011 08:13:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1282) Rar classes are not
 made available to deployments
In-Reply-To: <506537509.53413.1310642303654.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <213588182.53461.1310645603884.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen reassigned AS7-1282:
------------------------------------

    Assignee: Stefano Maestri


> Rar classes are not made available to deployments
> -------------------------------------------------
>
>                 Key: AS7-1282
>                 URL: https://issues.jboss.org/browse/AS7-1282
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Carlo de Wolf
>            Assignee: Stefano Maestri
>            Priority: Critical
>             Fix For: 7.1.0.CR1
>
>
> The rar classes are not made available to a deployment.
> {noformat}
> java.lang.ClassNotFoundException: org.hornetq.ra.inflow.HornetQActivationSpec from [Module "deployment.ejb3mdb.jar:main" from Service Module Loader]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> {noformat}
> JCA 1.6 20.3 Class Loading Requirements
> {quote}
> If a standalone resource adapter is configured to deliver messages to a message-
> driven bean in an application, the standalone resource adapter must be made
> available to the application.
> {quote}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 08:33:23 2011
From: jira-events at lists.jboss.org (Benjamin Browning (JIRA))
Date: Thu, 14 Jul 2011 08:33:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1283) Cookie-Based Sessions
	Broken
Message-ID: <125463836.53501.1310646803618.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Cookie-Based Sessions Broken
----------------------------

                 Key: AS7-1283
                 URL: https://issues.jboss.org/browse/AS7-1283
             Project: Application Server 7
          Issue Type: Bug
    Affects Versions: 7.0.0.Final
            Reporter: Benjamin Browning
            Priority: Blocker


See http://community.jboss.org/message/612763 and http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/003120.html.

Essentially cookie-based sessions are broken in major browsers and curl unless -Dorg.apache.tomcat.util.http.ServerCookie.FWD_SLASH_IS_SEPARATOR=false is passed on boot. It's likely a large percentage of the people that try AS7 Final will run into this issue and have to spend time trying to figure out why sessions aren't working.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 09:39:23 2011
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Thu, 14 Jul 2011 09:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1283) Cookie-Based Sessions
	Broken
In-Reply-To: <125463836.53501.1310646803618.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1101950793.53673.1310650763699.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jason Greene updated AS7-1283:
------------------------------

    Component/s: Web


> Cookie-Based Sessions Broken
> ----------------------------
>
>                 Key: AS7-1283
>                 URL: https://issues.jboss.org/browse/AS7-1283
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>            Reporter: Benjamin Browning
>            Priority: Blocker
>
> See http://community.jboss.org/message/612763 and http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/003120.html.
> Essentially cookie-based sessions are broken in major browsers and curl unless -Dorg.apache.tomcat.util.http.ServerCookie.FWD_SLASH_IS_SEPARATOR=false is passed on boot. It's likely a large percentage of the people that try AS7 Final will run into this issue and have to spend time trying to figure out why sessions aren't working.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 09:39:23 2011
From: jira-events at lists.jboss.org (Benjamin Browning (JIRA))
Date: Thu, 14 Jul 2011 09:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1283) Cookie-Based Sessions
	Broken
In-Reply-To: <125463836.53501.1310646803618.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <640918259.53676.1310650763793.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Benjamin Browning updated AS7-1283:
-----------------------------------

    Description: 
See http://community.jboss.org/message/612763 and http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/003120.html.

Essentially cookie-based sessions are broken in major browsers and curl unless -Dorg.apache.tomcat.util.http.ServerCookie.FWD_SLASH_IS_SEPARATOR=false is passed on boot. It's likely a large percentage of the people that try AS7 Final will run into this issue and have to spend time trying to figure out why sessions aren't working.

To summarize the above links, what's happening is the cookie's Path value is being enclosed in quotes. Browsers don't expect this and thus when the browser receives a cookie it doesn't send that cookie back on subsequent requests because the browser doesn't think the cookie's Path value matches the user's path.

  was:
See http://community.jboss.org/message/612763 and http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/003120.html.

Essentially cookie-based sessions are broken in major browsers and curl unless -Dorg.apache.tomcat.util.http.ServerCookie.FWD_SLASH_IS_SEPARATOR=false is passed on boot. It's likely a large percentage of the people that try AS7 Final will run into this issue and have to spend time trying to figure out why sessions aren't working.

    Component/s:     (was: Web)


> Cookie-Based Sessions Broken
> ----------------------------
>
>                 Key: AS7-1283
>                 URL: https://issues.jboss.org/browse/AS7-1283
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Final
>            Reporter: Benjamin Browning
>            Priority: Blocker
>
> See http://community.jboss.org/message/612763 and http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/003120.html.
> Essentially cookie-based sessions are broken in major browsers and curl unless -Dorg.apache.tomcat.util.http.ServerCookie.FWD_SLASH_IS_SEPARATOR=false is passed on boot. It's likely a large percentage of the people that try AS7 Final will run into this issue and have to spend time trying to figure out why sessions aren't working.
> To summarize the above links, what's happening is the cookie's Path value is being enclosed in quotes. Browsers don't expect this and thus when the browser receives a cookie it doesn't send that cookie back on subsequent requests because the browser doesn't think the cookie's Path value matches the user's path.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 09:39:23 2011
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Thu, 14 Jul 2011 09:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1283) Cookie-Based
	Sessions Broken
In-Reply-To: <125463836.53501.1310646803618.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1368393565.53681.1310650763894.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jason Greene reassigned AS7-1283:
---------------------------------

    Assignee: Remy Maucherat


> Cookie-Based Sessions Broken
> ----------------------------
>
>                 Key: AS7-1283
>                 URL: https://issues.jboss.org/browse/AS7-1283
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Final
>            Reporter: Benjamin Browning
>            Assignee: Remy Maucherat
>            Priority: Blocker
>
> See http://community.jboss.org/message/612763 and http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/003120.html.
> Essentially cookie-based sessions are broken in major browsers and curl unless -Dorg.apache.tomcat.util.http.ServerCookie.FWD_SLASH_IS_SEPARATOR=false is passed on boot. It's likely a large percentage of the people that try AS7 Final will run into this issue and have to spend time trying to figure out why sessions aren't working.
> To summarize the above links, what's happening is the cookie's Path value is being enclosed in quotes. Browsers don't expect this and thus when the browser receives a cookie it doesn't send that cookie back on subsequent requests because the browser doesn't think the cookie's Path value matches the user's path.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 09:41:23 2011
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Thu, 14 Jul 2011 09:41:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1283) Cookie-Based Sessions
	Broken
In-Reply-To: <125463836.53501.1310646803618.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1282460561.53686.1310650883670.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jason Greene updated AS7-1283:
------------------------------

    Fix Version/s: 7.0.1.Final


> Cookie-Based Sessions Broken
> ----------------------------
>
>                 Key: AS7-1283
>                 URL: https://issues.jboss.org/browse/AS7-1283
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Final
>            Reporter: Benjamin Browning
>            Assignee: Remy Maucherat
>            Priority: Blocker
>             Fix For: 7.0.1.Final
>
>
> See http://community.jboss.org/message/612763 and http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/003120.html.
> Essentially cookie-based sessions are broken in major browsers and curl unless -Dorg.apache.tomcat.util.http.ServerCookie.FWD_SLASH_IS_SEPARATOR=false is passed on boot. It's likely a large percentage of the people that try AS7 Final will run into this issue and have to spend time trying to figure out why sessions aren't working.
> To summarize the above links, what's happening is the cookie's Path value is being enclosed in quotes. Browsers don't expect this and thus when the browser receives a cookie it doesn't send that cookie back on subsequent requests because the browser doesn't think the cookie's Path value matches the user's path.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 09:43:23 2011
From: jira-events at lists.jboss.org (Radim Hanus (JIRA))
Date: Thu, 14 Jul 2011 09:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-9416) EJB3 SFSB performace
 problem: parallel calls are sequenced
Message-ID: <1327573270.53690.1310651003625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

EJB3 SFSB performace problem: parallel calls are sequenced
----------------------------------------------------------

                 Key: JBAS-9416
                 URL: https://issues.jboss.org/browse/JBAS-9416
             Project: Legacy JBoss Application Server 6 
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.0.Final
            Reporter: Radim Hanus


When a client looks up more SFSB of given type in dedicated threads and subsequently calls business methods then such calls are always sequenced.
Works fine in jboss-5.1.0

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 09:45:24 2011
From: jira-events at lists.jboss.org (Radim Hanus (JIRA))
Date: Thu, 14 Jul 2011 09:45:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-9416) EJB3 SFSB
 performace problem: parallel calls are sequenced
In-Reply-To: <1327573270.53690.1310651003625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1352678754.53704.1310651124124.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Radim Hanus commented on JBAS-9416:
-----------------------------------

I've got really simple sample where I may demonstrate this behaviour

> EJB3 SFSB performace problem: parallel calls are sequenced
> ----------------------------------------------------------
>
>                 Key: JBAS-9416
>                 URL: https://issues.jboss.org/browse/JBAS-9416
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Radim Hanus
>
> When a client looks up more SFSB of given type in dedicated threads and subsequently calls business methods then such calls are always sequenced.
> Works fine in jboss-5.1.0

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 09:48:23 2011
From: jira-events at lists.jboss.org (Josef Wegner (JIRA))
Date: Thu, 14 Jul 2011 09:48:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1284) Accessing
 localhost:8080 using JBoss Web Native causes
 java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
Message-ID: <2087989740.53707.1310651303687.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Accessing localhost:8080 using JBoss Web Native causes java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
--------------------------------------------------------------------------------------------------------------

                 Key: AS7-1284
                 URL: https://issues.jboss.org/browse/AS7-1284
             Project: Application Server 7
          Issue Type: Bug
          Components: CDI / Weld
    Affects Versions: 7.0.0.Final
         Environment: Darwin osx-en-jwegne.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
Java HotSpot(TM) Client VM (build 20.1-b02-384, mixed mode)

java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)
            Reporter: Josef Wegner
            Assignee: Stuart Douglas
            Priority: Minor


Hi,

accessing http://localhost:8080 using JBoss Web Native 2.0.9 (self compiled for x64 and downloaded from http://www.jboss.org/jbossweb/downloads/jboss-native-2-0-9.html for i386) causes following stack trace:

{quote}
15:23:18,710 ERROR [org.apache.coyote.http11.Http11AprProtocol] (http--127.0.0.1-8080-1) Error reading request, ignored: java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
	at org.apache.tomcat.jni.Socket.setrbb(Native Method)
	at org.apache.coyote.http11.InternalAprInputBuffer.setSocket(InternalAprInputBuffer.java:202)
	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:825)
	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
Caused by: java.lang.ClassNotFoundException: sun.nio.ch.DirectBuffer from [Module "org.jboss.as.web:main" from local module loader @39e87719 (roots: /Users/jwegne/Tools/jboss-as-web-7.0.0.Final/modules)]
	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
	... 6 more
{quote}

This happens with only when using JDK 1.6 provided by Apple. OpenJDK 1.7 (self-compiled) works, though.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 09:48:23 2011
From: jira-events at lists.jboss.org (Josef Wegner (JIRA))
Date: Thu, 14 Jul 2011 09:48:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1285) Accessing
 localhost:8080 using JBoss Web Native causes
 java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
Message-ID: <347498200.53709.1310651303736.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Accessing localhost:8080 using JBoss Web Native causes java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
--------------------------------------------------------------------------------------------------------------

                 Key: AS7-1285
                 URL: https://issues.jboss.org/browse/AS7-1285
             Project: Application Server 7
          Issue Type: Bug
          Components: CDI / Weld
    Affects Versions: 7.0.0.Final
         Environment: Darwin osx-en-jwegne.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
Java HotSpot(TM) Client VM (build 20.1-b02-384, mixed mode)

java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)
            Reporter: Josef Wegner
            Assignee: Stuart Douglas
            Priority: Minor


Hi,

accessing http://localhost:8080 using JBoss Web Native 2.0.9 (self compiled for x64 and downloaded from http://www.jboss.org/jbossweb/downloads/jboss-native-2-0-9.html for i386) causes following stack trace:

{quote}
15:23:18,710 ERROR [org.apache.coyote.http11.Http11AprProtocol] (http--127.0.0.1-8080-1) Error reading request, ignored: java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
	at org.apache.tomcat.jni.Socket.setrbb(Native Method)
	at org.apache.coyote.http11.InternalAprInputBuffer.setSocket(InternalAprInputBuffer.java:202)
	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:825)
	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
Caused by: java.lang.ClassNotFoundException: sun.nio.ch.DirectBuffer from [Module "org.jboss.as.web:main" from local module loader @39e87719 (roots: /Users/jwegne/Tools/jboss-as-web-7.0.0.Final/modules)]
	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
	... 6 more
{quote}

This happens with only when using JDK 1.6 provided by Apple. OpenJDK 1.7 (self-compiled) works, though.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 09:50:27 2011
From: jira-events at lists.jboss.org (Radim Hanus (JIRA))
Date: Thu, 14 Jul 2011 09:50:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-9416) EJB3 SFSB performace
 problem: parallel calls are sequenced
In-Reply-To: <1327573270.53690.1310651003625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <405732242.53718.1310651427762.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Radim Hanus updated JBAS-9416:
------------------------------

    Attachment: sfsbtest.zip


Steps to reproduce:
1. unpack
2. have java6, ant1.7 or higher, jboss-6.0
3. env property JBOSS_HOME
3. enable DEBUG level for category sfsbtest
4. type "ant all"
5. examine server.log -> calls are sequenced

> EJB3 SFSB performace problem: parallel calls are sequenced
> ----------------------------------------------------------
>
>                 Key: JBAS-9416
>                 URL: https://issues.jboss.org/browse/JBAS-9416
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Radim Hanus
>         Attachments: sfsbtest.zip
>
>
> When a client looks up more SFSB of given type in dedicated threads and subsequently calls business methods then such calls are always sequenced.
> Works fine in jboss-5.1.0

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 09:52:23 2011
From: jira-events at lists.jboss.org (Radim Hanus (JIRA))
Date: Thu, 14 Jul 2011 09:52:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (JBAS-9416) EJB3
 SFSB performace problem: parallel calls are sequenced
In-Reply-To: <1327573270.53690.1310651003625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1805108141.53734.1310651543621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Radim Hanus edited comment on JBAS-9416 at 7/14/11 9:51 AM:
------------------------------------------------------------

Steps to reproduce:
1. unpack
2. have java6, ant1.7 or higher, jboss-6.0
3. env property JBOSS_HOME points to jboss-6.0
3. enable DEBUG level for category sfsbtest
4. type "ant all"
5. examine server.log -> calls are sequenced

      was (Author: rhanus):
    Steps to reproduce:
1. unpack
2. have java6, ant1.7 or higher, jboss-6.0
3. env property JBOSS_HOME
3. enable DEBUG level for category sfsbtest
4. type "ant all"
5. examine server.log -> calls are sequenced
  
> EJB3 SFSB performace problem: parallel calls are sequenced
> ----------------------------------------------------------
>
>                 Key: JBAS-9416
>                 URL: https://issues.jboss.org/browse/JBAS-9416
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Radim Hanus
>         Attachments: sfsbtest.zip
>
>
> When a client looks up more SFSB of given type in dedicated threads and subsequently calls business methods then such calls are always sequenced.
> Works fine in jboss-5.1.0

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 10:17:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Thu, 14 Jul 2011 10:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1278) CNFE for module
	javax.mail.api
In-Reply-To: <661207037.52678.1310626823982.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1685726407.53789.1310653043870.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd resolved AS7-1278.
------------------------------

    Fix Version/s: 7.0.1.Final
                   7.1.0.Alpha1
       Resolution: Done


> CNFE for module javax.mail.api
> ------------------------------
>
>                 Key: AS7-1278
>                 URL: https://issues.jboss.org/browse/AS7-1278
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Modules
>    Affects Versions: 7.0.0.Final
>         Environment: 7.1.0.Alpha1 Jenkins build 1402
>            Reporter: Juergen Zimmermann
>            Assignee: David Lloyd
>             Fix For: 7.0.1.Final, 7.1.0.Alpha1
>
>
> When I try to send an email via JavaMail I get a CNFE regarding the module "javax.mail.api:main". The missing class javax.net.ssl.SSLPeerUnverifiedException is part of Oracle's JDK in jsse.jar.
> Stacktrace:
> 08:33:31,553 ERROR [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (RMI TCP Connection(11)-127.0.0.1) Failed: de.swe.test.KundenverwaltungTest.createPrivatkunde: javax.ejb.EJBTransactionRolledbackException: Unexpected Error
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:157)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:251)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.supports(CMTTxInterceptor.java:466)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:237)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
> 	at de.swe.kundenverwaltung.service.KundenverwaltungListener$$$view138.sendEmail(Unknown Source) [test.jar:]
> 	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.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
> 	at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
> 	at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
> 	at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:125) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:62) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:125) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
> 	at de.swe.kundenverwaltung.service.KundenverwaltungListener$Proxy$_$$_Weld$Proxy$.sendEmail(KundenverwaltungListener$Proxy$_$$_Weld$Proxy$.java) [test.jar:]
> 	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.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
> 	at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
> 	at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
> 	at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
> 	at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
> 	at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
> 	at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
> 	at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:282) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
> 	at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:265) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
> 	at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:234) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
> 	at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:635) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
> 	at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:628) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
> 	at org.jboss.weld.event.EventImpl.fire(EventImpl.java:75) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
> 	at de.swe.kundenverwaltung.service.Kundenverwaltung.createKunde(Kundenverwaltung.java:374) [test.jar:]
> 	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.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:114) [jboss-as-weld-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:122) [jboss-as-weld-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
> 	at de.swe.util.LogInterceptor.log(LogInterceptor.java:81) [test.jar:]
> 	at sun.reflect.GeneratedMethodAccessor197.invoke(Unknown Source) [: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:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:45) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$ComponentDispatcherInterceptor.processInvocation(ViewDescription.java:202)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:67)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:271)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.required(CMTTxInterceptor.java:377)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:233)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
> 	at de.swe.kundenverwaltung.service.Kundenverwaltung$$$view131.createKunde(Unknown Source) [test.jar:]
> 	at de.swe.test.KundenverwaltungTest.createPrivatkunde(KundenverwaltungTest.java:262) [test.jar:]
> 	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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [arquillian-service:]
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [arquillian-service:]
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) [arquillian-service:]
> 	at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:246) [arquillian-service:]
> 	at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) [arquillian-service:]
> 	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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) [arquillian-service:]
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) [arquillian-service:]
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134) [arquillian-service:]
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114) [arquillian-service:]
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) [arquillian-service:]
> 	at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38) [arquillian-service:]
> 	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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) [arquillian-service:]
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) [arquillian-service:]
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:82) [arquillian-service:]
> 	at sun.reflect.GeneratedMethodAccessor199.invoke(Unknown Source) [: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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) [arquillian-service:]
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:68) [arquillian-service:]
> 	at sun.reflect.GeneratedMethodAccessor196.invoke(Unknown Source) [: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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) [arquillian-service:]
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:54) [arquillian-service:]
> 	at sun.reflect.GeneratedMethodAccessor195.invoke(Unknown Source) [: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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) [arquillian-service:]
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:134) [arquillian-service:]
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) [arquillian-service:]
> 	at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:239) [arquillian-service:]
> 	at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:202) [arquillian-service:]
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:290) [arquillian-service:]
> 	at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:45) [arquillian-service:]
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:216) [arquillian-service:]
> 	at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110) [arquillian-service:]
> 	at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79) [arquillian-service:]
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71) [arquillian-service:]
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49) [arquillian-service:]
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) [arquillian-service:]
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) [arquillian-service:]
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) [arquillian-service:]
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) [arquillian-service:]
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) [arquillian-service:]
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:161) [arquillian-service:]
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:290) [arquillian-service:]
> 	at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:45) [arquillian-service:]
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:175) [arquillian-service:]
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:236) [arquillian-service:]
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:123) [arquillian-service:]
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:157) [arquillian-service:]
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:136) [arquillian-service:]
> 	at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:65) [arquillian-service:]
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:152) [arquillian-service:]
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodRemote(JMXTestRunner.java:112) [arquillian-service:]
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethodRemote(ArquillianService.java:205) [arquillian-service:]
> 	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 com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93) [:1.6.0_26]
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27) [:1.6.0_26]
> 	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208) [:1.6.0_26]
> 	at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120) [:1.6.0_26]
> 	at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262) [:1.6.0_26]
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836) [:1.6.0_26]
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761) [:1.6.0_26]
> 	at org.jboss.as.jmx.tcl.TcclMBeanServer.invoke(TcclMBeanServer.java:214)
> 	at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427) [:1.6.0_26]
> 	at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72) [:1.6.0_26]
> 	at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265) [:1.6.0_26]
> 	at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360) [:1.6.0_26]
> 	at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788) [:1.6.0_26]
> 	at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source) [: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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) [:1.6.0_26]
> 	at sun.rmi.transport.Transport$1.run(Transport.java:159) [:1.6.0_26]
> 	at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_26]
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:155) [:1.6.0_26]
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535) [:1.6.0_26]
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) [:1.6.0_26]
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) [:1.6.0_26]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]
> Caused by: java.lang.NoClassDefFoundError: javax/net/ssl/SSLPeerUnverifiedException
> 	at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1900) [mail-1.4.4.jar:1.4.4]
> 	at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:638) [mail-1.4.4.jar:1.4.4]
> 	at javax.mail.Service.connect(Service.java:317) [mail-1.4.4.jar:1.4.4]
> 	at javax.mail.Service.connect(Service.java:176) [mail-1.4.4.jar:1.4.4]
> 	at javax.mail.Service.connect(Service.java:125) [mail-1.4.4.jar:1.4.4]
> 	at javax.mail.Transport.send0(Transport.java:194) [mail-1.4.4.jar:1.4.4]
> 	at javax.mail.Transport.send(Transport.java:124) [mail-1.4.4.jar:1.4.4]
> 	at de.swe.kundenverwaltung.service.KundenverwaltungListener.sendEmail(KundenverwaltungListener.java:74) [test.jar:]
> 	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.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:114) [jboss-as-weld-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:122) [jboss-as-weld-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
> 	at de.swe.util.LogInterceptor.log(LogInterceptor.java:81) [test.jar:]
> 	at sun.reflect.GeneratedMethodAccessor197.invoke(Unknown Source) [: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:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:45) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$ComponentDispatcherInterceptor.processInvocation(ViewDescription.java:202)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:67)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:247)
> 	... 190 more
> Caused by: java.lang.ClassNotFoundException: javax.net.ssl.SSLPeerUnverifiedException from [Module "javax.mail.api:main" from local module loader @a6d51e (roots: C:\Software\jboss-7.1.0.Alpha1-b1402\modules)]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191) [jboss-modules.jar:1.0.1.GA]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358) [jboss-modules.jar:1.0.1.GA]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330) [jboss-modules.jar:1.0.1.GA]
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307) [jboss-modules.jar:1.0.1.GA]
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101) [jboss-modules.jar:1.0.1.GA]
> 	... 234 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 10:25:23 2011
From: jira-events at lists.jboss.org (Radim Hanus (JIRA))
Date: Thu, 14 Jul 2011 10:25:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-9416) EJB3 SFSB performace
 problem: parallel calls are sequenced
In-Reply-To: <1327573270.53690.1310651003625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1198125206.53825.1310653523706.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Radim Hanus updated JBAS-9416:
------------------------------

    Attachment: jboss-5.1_server.log
                jboss-6.0_server.log


> EJB3 SFSB performace problem: parallel calls are sequenced
> ----------------------------------------------------------
>
>                 Key: JBAS-9416
>                 URL: https://issues.jboss.org/browse/JBAS-9416
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Radim Hanus
>         Attachments: jboss-5.1_server.log, jboss-6.0_server.log, sfsbtest.zip
>
>
> When a client looks up more SFSB of given type in dedicated threads and subsequently calls business methods then such calls are always sequenced.
> Works fine in jboss-5.1.0

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 10:30:24 2011
From: jira-events at lists.jboss.org (Radim Hanus (JIRA))
Date: Thu, 14 Jul 2011 10:30:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (JBAS-9416) EJB3
 SFSB performace problem: parallel calls are sequenced
In-Reply-To: <1327573270.53690.1310651003625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1642897124.53848.1310653824047.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Radim Hanus edited comment on JBAS-9416 at 7/14/11 10:29 AM:
-------------------------------------------------------------

I've got really simple sample where I may demonstrate this behaviour:
- client looks up in separate threads SFSB DummyEJB and calls its methods
- method getNext() of interest sleeps for 1s to give a chance other thread to run

      was (Author: rhanus):
    I've got really simple sample where I may demonstrate this behaviour
  
> EJB3 SFSB performace problem: parallel calls are sequenced
> ----------------------------------------------------------
>
>                 Key: JBAS-9416
>                 URL: https://issues.jboss.org/browse/JBAS-9416
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Radim Hanus
>         Attachments: jboss-5.1_server.log, jboss-6.0_server.log, sfsbtest.zip
>
>
> When a client looks up more SFSB of given type in dedicated threads and subsequently calls business methods then such calls are always sequenced.
> Works fine in jboss-5.1.0

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 10:32:23 2011
From: jira-events at lists.jboss.org (Radim Hanus (JIRA))
Date: Thu, 14 Jul 2011 10:32:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (JBAS-9416) EJB3
 SFSB performace problem: parallel calls are sequenced
In-Reply-To: <1327573270.53690.1310651003625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1783857160.53856.1310653943911.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Radim Hanus edited comment on JBAS-9416 at 7/14/11 10:31 AM:
-------------------------------------------------------------

Steps to reproduce:
1. unpack sfsbtest.zip
2. have java6, ant1.7 or higher, jboss-6.0
3. env property JBOSS_HOME points to jboss-6.0
3. enable DEBUG level for category sfsbtest
4. type "ant all" to deploy 2 jar into default configuration
5. examine server.log -> calls are sequenced

      was (Author: rhanus):
    Steps to reproduce:
1. unpack
2. have java6, ant1.7 or higher, jboss-6.0
3. env property JBOSS_HOME points to jboss-6.0
3. enable DEBUG level for category sfsbtest
4. type "ant all"
5. examine server.log -> calls are sequenced
  
> EJB3 SFSB performace problem: parallel calls are sequenced
> ----------------------------------------------------------
>
>                 Key: JBAS-9416
>                 URL: https://issues.jboss.org/browse/JBAS-9416
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Radim Hanus
>         Attachments: jboss-5.1_server.log, jboss-6.0_server.log, sfsbtest.zip
>
>
> When a client looks up more SFSB of given type in dedicated threads and subsequently calls business methods then such calls are always sequenced.
> Works fine in jboss-5.1.0

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 10:32:24 2011
From: jira-events at lists.jboss.org (Radim Hanus (JIRA))
Date: Thu, 14 Jul 2011 10:32:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (JBAS-9416) EJB3
 SFSB performace problem: parallel calls are sequenced
In-Reply-To: <1327573270.53690.1310651003625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1444686845.53860.1310653944160.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Radim Hanus edited comment on JBAS-9416 at 7/14/11 10:31 AM:
-------------------------------------------------------------

I've got really simple sample where I may reproduce this behaviour:
- client looks up in separate threads SFSB DummyEJB and calls its methods
- method getNext() of interest sleeps for 1s to give a chance other thread to run

      was (Author: rhanus):
    I've got really simple sample where I may demonstrate this behaviour:
- client looks up in separate threads SFSB DummyEJB and calls its methods
- method getNext() of interest sleeps for 1s to give a chance other thread to run
  
> EJB3 SFSB performace problem: parallel calls are sequenced
> ----------------------------------------------------------
>
>                 Key: JBAS-9416
>                 URL: https://issues.jboss.org/browse/JBAS-9416
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Radim Hanus
>         Attachments: jboss-5.1_server.log, jboss-6.0_server.log, sfsbtest.zip
>
>
> When a client looks up more SFSB of given type in dedicated threads and subsequently calls business methods then such calls are always sequenced.
> Works fine in jboss-5.1.0

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 10:36:25 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 14 Jul 2011 10:36:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1286) IronJacamar
	1.0.0.Final
Message-ID: <603039307.53873.1310654185047.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

IronJacamar 1.0.0.Final
-----------------------

                 Key: AS7-1286
                 URL: https://issues.jboss.org/browse/AS7-1286
             Project: Application Server 7
          Issue Type: Component  Upgrade
          Components: Build System
            Reporter: Jesper Pedersen
            Assignee: Paul Gier
             Fix For: 7.1.0.Alpha1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 10:36:25 2011
From: jira-events at lists.jboss.org (Radim Hanus (JIRA))
Date: Thu, 14 Jul 2011 10:36:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-9416) EJB3 SFSB
 performace problem: parallel calls are sequenced
In-Reply-To: <1327573270.53690.1310651003625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2142685938.53878.1310654185236.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Radim Hanus commented on JBAS-9416:
-----------------------------------

jboss-6.0_server.log:
2011-07-14 15:09:24,109 DEBUG [sfsbtest.bean.DummyBean] (Test2) getNext() Test2: begin
2011-07-14 15:09:25,119 DEBUG [sfsbtest.bean.DummyBean] (Test2) getNext() Test2: end

jboss-5.1_server.log:
2011-07-14 16:20:48,047 DEBUG [sfsbtest.bean.DummyBean] (Test1) getNext() Test1: begin
2011-07-14 16:20:49,014 DEBUG [sfsbtest.bean.DummyBean] (Test2) getNext() Test2: end

2011-07-14 16:20:49,014 DEBUG [sfsbtest.bean.DummyBean] (Test2) getNext() Test2: begin
2011-07-14 16:20:49,061 DEBUG [sfsbtest.bean.DummyBean] (Test1) getNext() Test1: end


> EJB3 SFSB performace problem: parallel calls are sequenced
> ----------------------------------------------------------
>
>                 Key: JBAS-9416
>                 URL: https://issues.jboss.org/browse/JBAS-9416
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Radim Hanus
>         Attachments: jboss-5.1_server.log, jboss-6.0_server.log, sfsbtest.zip
>
>
> When a client looks up more SFSB of given type in dedicated threads and subsequently calls business methods then such calls are always sequenced.
> Works fine in jboss-5.1.0

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 10:36:25 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 14 Jul 2011 10:36:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1286) IronJacamar
	1.0.0.Final
In-Reply-To: <603039307.53873.1310654185047.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <991653165.53881.1310654185337.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen reassigned AS7-1286:
------------------------------------

    Assignee: Jesper Pedersen  (was: Paul Gier)


> IronJacamar 1.0.0.Final
> -----------------------
>
>                 Key: AS7-1286
>                 URL: https://issues.jboss.org/browse/AS7-1286
>             Project: Application Server 7
>          Issue Type: Component  Upgrade
>          Components: Build System
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 7.1.0.Alpha1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 10:40:24 2011
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 14 Jul 2011 10:40:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1287) Fix scm information
 in jar Manifests
In-Reply-To: <1601866123.53902.1310654424159.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1503631106.53904.1310654424220.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Gier updated AS7-1287:
---------------------------

    Description: 
The Scm-Url in the jar manifests currently shows the jboss-parent pom git URL.  This should be fixed to show the correct URL.
"Scm-Url: scm:git:git at github.com:jboss/jboss-parent-pom.git/jboss-as-pa
 rent/"

  was:The Scm-Url in the jar manifests currently shows the jboss-parent pom git URL.  This should be fixed to show the correct URL.



> Fix scm information in jar Manifests
> ------------------------------------
>
>                 Key: AS7-1287
>                 URL: https://issues.jboss.org/browse/AS7-1287
>             Project: Application Server 7
>          Issue Type: Enhancement
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>            Priority: Minor
>             Fix For: 7.0.1.Final
>
>
> The Scm-Url in the jar manifests currently shows the jboss-parent pom git URL.  This should be fixed to show the correct URL.
> "Scm-Url: scm:git:git at github.com:jboss/jboss-parent-pom.git/jboss-as-pa
>  rent/"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 10:40:24 2011
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 14 Jul 2011 10:40:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1287) Fix scm information
 in jar Manifests
Message-ID: <1601866123.53902.1310654424159.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Fix scm information in jar Manifests
------------------------------------

                 Key: AS7-1287
                 URL: https://issues.jboss.org/browse/AS7-1287
             Project: Application Server 7
          Issue Type: Enhancement
            Reporter: Paul Gier
            Assignee: Paul Gier
            Priority: Minor
             Fix For: 7.0.1.Final


The Scm-Url in the jar manifests currently shows the jboss-parent pom git URL.  This should be fixed to show the correct URL.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 10:40:24 2011
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Thu, 14 Jul 2011 10:40:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1287) Fix scm information
 in jar Manifests
In-Reply-To: <1601866123.53902.1310654424159.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <486088850.53905.1310654424255.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Gier updated AS7-1287:
---------------------------

    Description: 
The Scm-Url in the jar manifests currently shows the jboss-parent pom git URL.  This should be fixed to show the correct URL.
"Scm-Url: scm:git:git at github.com:jboss/jboss-parent-pom.git/jboss-as-parent/"

  was:
The Scm-Url in the jar manifests currently shows the jboss-parent pom git URL.  This should be fixed to show the correct URL.
"Scm-Url: scm:git:git at github.com:jboss/jboss-parent-pom.git/jboss-as-pa
 rent/"



> Fix scm information in jar Manifests
> ------------------------------------
>
>                 Key: AS7-1287
>                 URL: https://issues.jboss.org/browse/AS7-1287
>             Project: Application Server 7
>          Issue Type: Enhancement
>            Reporter: Paul Gier
>            Assignee: Paul Gier
>            Priority: Minor
>             Fix For: 7.0.1.Final
>
>
> The Scm-Url in the jar manifests currently shows the jboss-parent pom git URL.  This should be fixed to show the correct URL.
> "Scm-Url: scm:git:git at github.com:jboss/jboss-parent-pom.git/jboss-as-parent/"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 10:58:23 2011
From: jira-events at lists.jboss.org (Radim Hanus (JIRA))
Date: Thu, 14 Jul 2011 10:58:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-9416) EJB3 SFSB performace
 problem: parallel calls are sequenced
In-Reply-To: <1327573270.53690.1310651003625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1483862234.53971.1310655503876.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Radim Hanus updated JBAS-9416:
------------------------------

    Attachment: thread_dump.txt


added jvm thread dump
while the first thread is sleeping the second one tries to obtain a lock in ContainerManagedConcurrencyInterceptor

> EJB3 SFSB performace problem: parallel calls are sequenced
> ----------------------------------------------------------
>
>                 Key: JBAS-9416
>                 URL: https://issues.jboss.org/browse/JBAS-9416
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Radim Hanus
>         Attachments: jboss-5.1_server.log, jboss-6.0_server.log, sfsbtest.zip, thread_dump.txt
>
>
> When a client looks up more SFSB of given type in dedicated threads and subsequently calls business methods then such calls are always sequenced.
> Works fine in jboss-5.1.0

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 10:58:24 2011
From: jira-events at lists.jboss.org (Radim Hanus (JIRA))
Date: Thu, 14 Jul 2011 10:58:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (JBAS-9416) EJB3
 SFSB performace problem: parallel calls are sequenced
In-Reply-To: <1327573270.53690.1310651003625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <171438372.53977.1310655504231.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Radim Hanus edited comment on JBAS-9416 at 7/14/11 10:58 AM:
-------------------------------------------------------------

added jvm thread dump
while the first thread is sleeping the second one tries to obtain a lock in ContainerManagedConcurrencyInterceptor
why ?

      was (Author: rhanus):
    added jvm thread dump
while the first thread is sleeping the second one tries to obtain a lock in ContainerManagedConcurrencyInterceptor
  
> EJB3 SFSB performace problem: parallel calls are sequenced
> ----------------------------------------------------------
>
>                 Key: JBAS-9416
>                 URL: https://issues.jboss.org/browse/JBAS-9416
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Radim Hanus
>         Attachments: jboss-5.1_server.log, jboss-6.0_server.log, sfsbtest.zip, thread_dump.txt
>
>
> When a client looks up more SFSB of given type in dedicated threads and subsequently calls business methods then such calls are always sequenced.
> Works fine in jboss-5.1.0

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 11:13:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Thu, 14 Jul 2011 11:13:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1260) JGroups subsystem
 fails to setup some protocol stacks.
In-Reply-To: <1568744513.48245.1310478143759.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <8324401.53992.1310656403702.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro resolved AS7-1260.
-------------------------------

    Fix Version/s: 7.0.1.Final
                   7.1.0.Alpha1
       Resolution: Done


> JGroups subsystem fails to setup some protocol stacks.
> ------------------------------------------------------
>
>                 Key: AS7-1260
>                 URL: https://issues.jboss.org/browse/AS7-1260
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.Final
>            Reporter: Trustin Lee
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 7.0.1.Final, 7.1.0.Alpha1
>
>
> After upgrading from AS 7.0.0.CR1 to AS 7.0.0.Final, I started to see an exception raised by org.jboss.as.clustering.jgroups.JChannelFactory:
> {code}
> 22:11:54,040 ERROR [stderr] (MSC service thread 1-1) java.lang.IllegalArgumentException: org.jgroups.ChannelException: unable to setup the protocol stack
> 22:11:54,040 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.ChannelProvider.getJGroupsChannel(ChannelProvider.java:71)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:273)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:226)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:254)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:148)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at java.lang.reflect.Method.invoke(Method.java:597)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:918)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:711)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:611)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:176)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:171)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.CacheImpl.start(CacheImpl.java:366)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:559)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:479)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:84)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:73)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:73)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at java.lang.Thread.run(Thread.java:680)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) Caused by: org.jgroups.ChannelException: unable to setup the protocol stack
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.init(JChannel.java:1728)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.<init>(JChannel.java:249)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.jgroups.JChannelFactory$JChannel.<init>(JChannelFactory.java:269)
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:69)
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.ChannelProvider.getJGroupsChannel(ChannelProvider.java:67)
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	... 26 more
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) Caused by: java.lang.IllegalArgumentException: the following properties in PING are not recognized: {bind_addr=192.168.0.196}
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.createLayer(Configurator.java:460)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.createProtocols(Configurator.java:393)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:88)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:55)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:534)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.init(JChannel.java:1725)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	... 30 more
> {code}
> (Actually, the exception was being swallowed by Infinispan, so I had to modify the source code in Infinispan.)
> Reverting back only the JGroups subsystem to 7.0.0.CR1 fixes the problem for UDP stack.  TCP stack still fails when configuring MPING:
> {code}
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) Caused by: java.lang.IllegalArgumentException: the following properties in MPING are not recognized: {start_port=0}
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.createLayer(Configurator.java:460)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.createProtocols(Configurator.java:393)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:88)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:55)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:534)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.JChannel.init(JChannel.java:1725)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	... 30 more
> {code}
> The offending subsystem configuration is:
> {code}
>         <subsystem xmlns="urn:jboss:domain:jgroups:1.0" default-stack="udp">
>             <stack name="udp">
>                 <transport type="UDP"
>                            socket-binding="jgroups-udp"
>                            default-executor="jgroups"
>                            oob-executor="jgroups-oob"
>                            timer-executor="jgroups-timer"/>
>                 <protocol type="PING"/>
>                 <protocol type="MERGE2"/>
>                 <protocol type="FD_SOCK"/>
>                 <protocol type="FD"/>
>                 <protocol type="VERIFY_SUSPECT"/>
>                 <protocol type="BARRIER"/>
>                 <protocol type="pbcast.NAKACK"/>
>                 <protocol type="UNICAST"/>
>                 <protocol type="pbcast.STABLE"/>
>                 <protocol type="VIEW_SYNC"/>
>                 <protocol type="pbcast.GMS"/>
>                 <protocol type="UFC"/>
>                 <protocol type="MFC"/>
>                 <protocol type="FRAG2"/>
>                 <protocol type="pbcast.STREAMING_STATE_TRANSFER"/>
>                 <protocol type="pbcast.FLUSH"/>
>             </stack>
>             <stack name="tcp">
>                 <transport type="TCP"
>                            socket-binding="jgroups-tcp"
>                            default-executor="jgroups"
>                            oob-executor="jgroups-oob"
>                            timer-executor="jgroups-timer"/>
>                 <protocol type="MPING" socket-binding="jgroups-mping"/>
>                 <protocol type="MERGE2"/>
>                 <protocol type="FD_SOCK"/>
>                 <protocol type="FD"/>
>                 <protocol type="VERIFY_SUSPECT"/>
>                 <protocol type="BARRIER"/>
>                 <protocol type="pbcast.NAKACK"/>
>                 <protocol type="UNICAST"/>
>                 <protocol type="pbcast.STABLE"/>
>                 <protocol type="VIEW_SYNC"/>
>                 <protocol type="pbcast.GMS"/>
>                 <protocol type="UFC"/>
>                 <protocol type="MFC"/>
>                 <protocol type="FRAG2"/>
>                 <protocol type="pbcast.STREAMING_STATE_TRANSFER"/>
>                 <protocol type="pbcast.FLUSH"/>
>             </stack>
>         </subsystem>
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 11:15:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Thu, 14 Jul 2011 11:15:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1266) Infinispan caches
 should have jmx statistics enabled
In-Reply-To: <163586529.49017.1310491883658.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1463239296.53998.1310656523956.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro resolved AS7-1266.
-------------------------------

    Fix Version/s: 7.1.0.Alpha1
       Resolution: Done


> Infinispan caches should have jmx statistics enabled
> ----------------------------------------------------
>
>                 Key: AS7-1266
>                 URL: https://issues.jboss.org/browse/AS7-1266
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 7.0.1.Final, 7.1.0.Alpha1
>
>
> Infinispan cache managers have global jmx statistics enabled, but not individual caches.  Update EmbeddedCacheManagerService to enable this on the default cache if an mbean server is present.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 11:15:24 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Thu, 14 Jul 2011 11:15:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1265) Infinispan cache
 containers registered using DefaultDomain JMX domain
In-Reply-To: <92237816.49014.1310491703613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <178204933.54006.1310656524217.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro resolved AS7-1265.
-------------------------------

    Fix Version/s: 7.1.0.Alpha1
       Resolution: Done


> Infinispan cache containers registered using DefaultDomain JMX domain
> ---------------------------------------------------------------------
>
>                 Key: AS7-1265
>                 URL: https://issues.jboss.org/browse/AS7-1265
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>            Priority: Minor
>             Fix For: 7.0.1.Final, 7.1.0.Alpha1
>
>
> Fix the jmx domain used to register infinispan cache managers to match the convention used by other AS components.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 11:19:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Thu, 14 Jul 2011 11:19:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCLUSTER-293) Reimplement
 distributed sessions using single cache instance for all web applications
In-Reply-To: <1166093193.36024.1300468725754.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <185425882.54024.1310656763938.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro resolved JBCLUSTER-293.
------------------------------------

    Fix Version/s:     (was: HA-Server-Cache-ISPN 1.1.0)
       Resolution: Out of Date


This is implemented in the AS7 codebase.

> Reimplement distributed sessions using single cache instance for all web applications
> -------------------------------------------------------------------------------------
>
>                 Key: JBCLUSTER-293
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-293
>             Project: JBoss Clustering
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: HA-Server-Cache-ISPN
>    Affects Versions: HA-Server-Cache-ISPN 1.0.0.Final 
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> To workaround ISPN-658, we should store all sessions for all web applications (with the same cache name) within a single cache, using a composite key that includes the host, context path, and session ID.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 11:19:24 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Thu, 14 Jul 2011 11:19:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCLUSTER-294) Drop ISPN-658
	workaround
In-Reply-To: <375464312.36039.1300468966340.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <506989292.54028.1310656764083.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro resolved JBCLUSTER-294.
------------------------------------

    Fix Version/s:     (was: HA-Server-ISPN 1.0.1.Final)
       Resolution: Out of Date


This is implemented in the AS7 codebase

> Drop ISPN-658 workaround
> ------------------------
>
>                 Key: JBCLUSTER-294
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-294
>             Project: JBoss Clustering
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: HA-Server-ISPN
>    Affects Versions: HA-Server-ISPN 1.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> Drop DefaultCacheContainer wrapper - and remove usage within DefaultCacheContainerFactory.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 11:31:23 2011
From: jira-events at lists.jboss.org (Jean-Frederic Clere (JIRA))
Date: Thu, 14 Jul 2011 11:31:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1285) Accessing
 localhost:8080 using JBoss Web Native causes
 java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
In-Reply-To: <347498200.53709.1310651303736.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2089028290.54106.1310657483663.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jean-Frederic Clere commented on AS7-1285:
------------------------------------------

The native of the .org is broken for "JDK 1.6 provided by Apple".
To compile it on your own you need to configure like:
CFLAGS="-m64 -arch x86_64" ./configure ...

> Accessing localhost:8080 using JBoss Web Native causes java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1285
>                 URL: https://issues.jboss.org/browse/AS7-1285
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 7.0.0.Final
>         Environment: Darwin osx-en-jwegne.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) Client VM (build 20.1-b02-384, mixed mode)
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)
>            Reporter: Josef Wegner
>            Assignee: Stuart Douglas
>            Priority: Minor
>
> Hi,
> accessing http://localhost:8080 using JBoss Web Native 2.0.9 (self compiled for x64 and downloaded from http://www.jboss.org/jbossweb/downloads/jboss-native-2-0-9.html for i386) causes following stack trace:
> {quote}
> 15:23:18,710 ERROR [org.apache.coyote.http11.Http11AprProtocol] (http--127.0.0.1-8080-1) Error reading request, ignored: java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> 	at org.apache.tomcat.jni.Socket.setrbb(Native Method)
> 	at org.apache.coyote.http11.InternalAprInputBuffer.setSocket(InternalAprInputBuffer.java:202)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:825)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: java.lang.ClassNotFoundException: sun.nio.ch.DirectBuffer from [Module "org.jboss.as.web:main" from local module loader @39e87719 (roots: /Users/jwegne/Tools/jboss-as-web-7.0.0.Final/modules)]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
> 	... 6 more
> {quote}
> This happens with only when using JDK 1.6 provided by Apple. OpenJDK 1.7 (self-compiled) works, though.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 11:52:40 2011
From: jira-events at lists.jboss.org (Josef Wegner (JIRA))
Date: Thu, 14 Jul 2011 11:52:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1285) Accessing
 localhost:8080 using JBoss Web Native causes
 java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
In-Reply-To: <347498200.53709.1310651303736.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <583408167.54124.1310658760468.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Josef Wegner commented on AS7-1285:
-----------------------------------

Thanks, but the self-compiled jnilib works fine on Tomcat 6/7 and JBoss 4/5/6 with 64-bit JDK.
Also, the same error happens if I use the pre-compiled one with 32-bit JDK.

> Accessing localhost:8080 using JBoss Web Native causes java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1285
>                 URL: https://issues.jboss.org/browse/AS7-1285
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 7.0.0.Final
>         Environment: Darwin osx-en-jwegne.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) Client VM (build 20.1-b02-384, mixed mode)
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)
>            Reporter: Josef Wegner
>            Assignee: Stuart Douglas
>            Priority: Minor
>
> Hi,
> accessing http://localhost:8080 using JBoss Web Native 2.0.9 (self compiled for x64 and downloaded from http://www.jboss.org/jbossweb/downloads/jboss-native-2-0-9.html for i386) causes following stack trace:
> {quote}
> 15:23:18,710 ERROR [org.apache.coyote.http11.Http11AprProtocol] (http--127.0.0.1-8080-1) Error reading request, ignored: java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> 	at org.apache.tomcat.jni.Socket.setrbb(Native Method)
> 	at org.apache.coyote.http11.InternalAprInputBuffer.setSocket(InternalAprInputBuffer.java:202)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:825)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: java.lang.ClassNotFoundException: sun.nio.ch.DirectBuffer from [Module "org.jboss.as.web:main" from local module loader @39e87719 (roots: /Users/jwegne/Tools/jboss-as-web-7.0.0.Final/modules)]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
> 	... 6 more
> {quote}
> This happens with only when using JDK 1.6 provided by Apple. OpenJDK 1.7 (self-compiled) works, though.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 12:32:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Thu, 14 Jul 2011 12:32:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1288) NPE in thread
	"vfs-shutdown"
Message-ID: <1423944013.54136.1310661143668.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

NPE in thread "vfs-shutdown" 
-----------------------------

                 Key: AS7-1288
                 URL: https://issues.jboss.org/browse/AS7-1288
             Project: Application Server 7
          Issue Type: Bug
          Components: VFS
    Affects Versions: 7.0.0.Final
         Environment: 7.1.0.Alpha1 Jenkins build 1402
            Reporter: Juergen Zimmermann
            Assignee: John Bailey


When I shutdown a standalone server I'm getting a NPE. The shutdown command is:
jboss-admin.bat --connect command=:shutdown

Console log:
...
18:24:55,990 INFO  [org.jboss.as.logging] Restored bootstrap log handlers
18:24:55,990 INFO  [org.jboss.as.jmx.JMXConnectorService] JMX remote connector stopped
18:24:56,075 INFO  [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: jboss-as-osgi-configadmin:7.1.0.Alpha1-SNAPSHOT
18:24:56,125 INFO  [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: org.apache.felix.log:1.0.0
18:24:56,230 INFO  [org.apache.catalina.core.StandardContext] Container org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/] has not been started
18:24:56,286 INFO  [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: org.apache.felix.configadmin:1.2.8
18:24:56,323 INFO  [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: jboss-osgi-logging:1.0.0
18:24:56,330 INFO  [com.arjuna.ats.jbossatx] ARJUNA32018: Destroying TransactionManagerService
18:24:56,331 INFO  [com.arjuna.ats.jbossatx] ARJUNA32014: Stopping transaction recovery manager
18:24:56,368 ERROR [stderr] Exception in thread "vfs-shutdown" java.lang.NullPointerException
18:24:56,368 ERROR [stderr] 	at org.jboss.vfs.TempFileProvider$DeleteTask.run(TempFileProvider.java:151)
18:24:56,368 ERROR [stderr] 	at org.jboss.vfs.TempFileProvider.close(TempFileProvider.java:132)
18:24:56,368 ERROR [stderr] 	at org.jboss.osgi.vfs30.VirtualFileAdaptor30$2.run(VirtualFileAdaptor30.java:94)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 12:36:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 14 Jul 2011 12:36:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-712) Publish all
 org.jboss.domain.* schemas to http://www.jboss.org/schema/
In-Reply-To: <260965286.28241.1304436318263.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <832261869.54143.1310661383742.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry resolved AS7-712.
----------------------------------

    Resolution: Done


> Publish all org.jboss.domain.* schemas to http://www.jboss.org/schema/
> ----------------------------------------------------------------------
>
>                 Key: AS7-712
>                 URL: https://issues.jboss.org/browse/AS7-712
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Blocker
>             Fix For: 7.0.1.Final
>
>
> http://community.jboss.org/wiki/JBossDTDs

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 12:38:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 14 Jul 2011 12:38:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1219) Add jboss-dmr
 documentation to the Admin Guide
In-Reply-To: <896759888.40346.1310056103706.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <601083255.54150.1310661503764.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned AS7-1219:
-------------------------------------

    Assignee: Brian Stansberry


> Add jboss-dmr documentation to the Admin Guide
> ----------------------------------------------
>
>                 Key: AS7-1219
>                 URL: https://issues.jboss.org/browse/AS7-1219
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 7.0.1.Final
>
>
> Basic documentation on DMR:
> 1) Purpose
> 2) Source location and maven coordinates
> 3) Description of the 2 public classes, ModelNode and ModelType, link to 1.0.0.Final code for each on github
> 4) Some simple examples
> 5) Fully document the string format, so people know how to read DMR output and how to write DMR input
> 6) Links to 5) above in the CLI docs, both in a place that describes how to read output and in a place that describes the format for parameter values in low-level operation requests 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 12:38:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 14 Jul 2011 12:38:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1220) Add native
 management (ModelControllerClient) API docs to the Admin Guide
In-Reply-To: <1106331286.40360.1310056463696.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <276692573.54160.1310661504060.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned AS7-1220:
-------------------------------------

    Assignee: Brian Stansberry


> Add native management  (ModelControllerClient) API docs to the Admin Guide
> --------------------------------------------------------------------------
>
>                 Key: AS7-1220
>                 URL: https://issues.jboss.org/browse/AS7-1220
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 7.0.1.Final
>
>
> There's some brief docs on configuring the native management interface. There is a separate JIRA for some fundamental docs on jboss-dmr. There will be a page in the "Core management concepts" section on what management resources, attributes and operations are.
> This task is to reference those elements and bring together a coherent picture of how to use the ModelControllerClient API.
> A subtask would be to add docs on the helper classes in controller-client, although I'm fine with deferring that bit until later in the AS 7.1 cycle,

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 12:40:23 2011
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ra=C3=BAl_Raja_Mart=C3=ADnez_=28JIRA=29?=)
Date: Thu, 14 Jul 2011 12:40:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1345) JDBC_PING fails to
 initialize table in mysql
In-Reply-To: <146558224.51504.1310586863624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2097678422.54167.1310661623685.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Ra?l Raja Mart?nez commented on JGRP-1345:
------------------------------------------

Bela, I will keep that in mind for next time. Sanne, I know my workaround is MYSQL specific and I understand you use standard SQL, I thought this issue was only on MYSQL that's why I commented about the workaround. Any standard MySQL installs on Mac like mine are potentially suffering the same issue. In any case I think this should be looked into as this prevents discovery from working and the only way to find out is to have trace turned on. The app silently fails later when it tries to insert data in tables that do not exist.
Thanks for looking into it and getting back to me.

> JDBC_PING fails to initialize table in mysql
> --------------------------------------------
>
>                 Key: JGRP-1345
>                 URL: https://issues.jboss.org/browse/JGRP-1345
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.12
>            Reporter: Ra?l Raja Mart?nez
>            Assignee: Sanne Grinovero
>             Fix For: 2.12.2, 3.0
>
>
> JDBC_PING fails to initialize DB table for discover when executing the following SQL:
> CREATE TABLE JGROUPSPING (own_addr varchar(200) NOT NULL, cluster_name varchar(200) NOT NULL, ping_data varbinary(5000) DEFAULT NULL, PRIMARY KEY (own_addr, cluster_name) )
> The statement results in "Specified key was too long; max key length is 1000 bytes"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Thu Jul 14 12:55:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 14 Jul 2011 12:55:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1284) Accessing
 localhost:8080 using JBoss Web Native causes
 java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
In-Reply-To: <2087989740.53707.1310651303687.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <161496887.54173.1310662523719.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-1284:
----------------------------------

       Assignee: Remy Maucherat  (was: Stuart Douglas)
    Component/s: Web
                     (was: CDI / Weld)


Discussing this issue with the reporter on #jboss-as7 yesterday, my original theory was the Apple JDK did not include sun.nio.ch.DirectBuffer. But that was incorrect; it is present.

David Lloyd's theory was it's a module configuration issue, where the class is not visible. He suggested this as a possible fix:

https://github.com/dmlloyd/jboss-as/commit/b150d42

I couldn't reproduce the issue and thus couldn't confirm the fix. I couldn't reproduce because my Mac is x86_64 and there are no jboss-native binaries for x86_64. I made a small attempt at building from source, but that failed, and that was all the cycles I had for this.

> Accessing localhost:8080 using JBoss Web Native causes java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1284
>                 URL: https://issues.jboss.org/browse/AS7-1284
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>         Environment: Darwin osx-en-jwegne.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) Client VM (build 20.1-b02-384, mixed mode)
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)
>            Reporter: Josef Wegner
>            Assignee: Remy Maucherat
>            Priority: Minor
>
> Hi,
> accessing http://localhost:8080 using JBoss Web Native 2.0.9 (self compiled for x64 and downloaded from http://www.jboss.org/jbossweb/downloads/jboss-native-2-0-9.html for i386) causes following stack trace:
> {quote}
> 15:23:18,710 ERROR [org.apache.coyote.http11.Http11AprProtocol] (http--127.0.0.1-8080-1) Error reading request, ignored: java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> 	at org.apache.tomcat.jni.Socket.setrbb(Native Method)
> 	at org.apache.coyote.http11.InternalAprInputBuffer.setSocket(InternalAprInputBuffer.java:202)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:825)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: java.lang.ClassNotFoundException: sun.nio.ch.DirectBuffer from [Module "org.jboss.as.web:main" from local module loader @39e87719 (roots: /Users/jwegne/Tools/jboss-as-web-7.0.0.Final/modules)]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
> 	... 6 more
> {quote}
> This happens with only when using JDK 1.6 provided by Apple. OpenJDK 1.7 (self-compiled) works, though.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 12:59:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 14 Jul 2011 12:59:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1285) Accessing
 localhost:8080 using JBoss Web Native causes
 java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
In-Reply-To: <347498200.53709.1310651303736.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1680746951.54194.1310662763678.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry resolved AS7-1285.
-----------------------------------

         Assignee:     (was: Stuart Douglas)
    Fix Version/s: No Release
       Resolution: Duplicate Issue


Resolving as duplicate of AS7-1284. Jean-Frederic, please see my comment on that issue.

> Accessing localhost:8080 using JBoss Web Native causes java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1285
>                 URL: https://issues.jboss.org/browse/AS7-1285
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 7.0.0.Final
>         Environment: Darwin osx-en-jwegne.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) Client VM (build 20.1-b02-384, mixed mode)
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)
>            Reporter: Josef Wegner
>            Priority: Minor
>             Fix For: No Release
>
>
> Hi,
> accessing http://localhost:8080 using JBoss Web Native 2.0.9 (self compiled for x64 and downloaded from http://www.jboss.org/jbossweb/downloads/jboss-native-2-0-9.html for i386) causes following stack trace:
> {quote}
> 15:23:18,710 ERROR [org.apache.coyote.http11.Http11AprProtocol] (http--127.0.0.1-8080-1) Error reading request, ignored: java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> 	at org.apache.tomcat.jni.Socket.setrbb(Native Method)
> 	at org.apache.coyote.http11.InternalAprInputBuffer.setSocket(InternalAprInputBuffer.java:202)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:825)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: java.lang.ClassNotFoundException: sun.nio.ch.DirectBuffer from [Module "org.jboss.as.web:main" from local module loader @39e87719 (roots: /Users/jwegne/Tools/jboss-as-web-7.0.0.Final/modules)]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
> 	... 6 more
> {quote}
> This happens with only when using JDK 1.6 provided by Apple. OpenJDK 1.7 (self-compiled) works, though.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 13:01:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 14 Jul 2011 13:01:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1284) Accessing
 localhost:8080 using JBoss Web Native causes
 java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
In-Reply-To: <2087989740.53707.1310651303687.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <388043972.54199.1310662883681.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on AS7-1284:
---------------------------------------

User reports his build of jboss-native works fine with other AS releases, which indicates there is something AS7 specific involved, hence David's module configuration fix.

User also reports AS7 + jboss-native works fine on other OS/JDK combos. That makes things a bit less clear; the theory is those JDK's nio implementations do not end up using classes in sun.nio, so the classloading issue does not manifest itself.

> Accessing localhost:8080 using JBoss Web Native causes java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1284
>                 URL: https://issues.jboss.org/browse/AS7-1284
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>         Environment: Darwin osx-en-jwegne.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) Client VM (build 20.1-b02-384, mixed mode)
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)
>            Reporter: Josef Wegner
>            Assignee: Remy Maucherat
>            Priority: Minor
>
> Hi,
> accessing http://localhost:8080 using JBoss Web Native 2.0.9 (self compiled for x64 and downloaded from http://www.jboss.org/jbossweb/downloads/jboss-native-2-0-9.html for i386) causes following stack trace:
> {quote}
> 15:23:18,710 ERROR [org.apache.coyote.http11.Http11AprProtocol] (http--127.0.0.1-8080-1) Error reading request, ignored: java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> 	at org.apache.tomcat.jni.Socket.setrbb(Native Method)
> 	at org.apache.coyote.http11.InternalAprInputBuffer.setSocket(InternalAprInputBuffer.java:202)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:825)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: java.lang.ClassNotFoundException: sun.nio.ch.DirectBuffer from [Module "org.jboss.as.web:main" from local module loader @39e87719 (roots: /Users/jwegne/Tools/jboss-as-web-7.0.0.Final/modules)]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
> 	... 6 more
> {quote}
> This happens with only when using JDK 1.6 provided by Apple. OpenJDK 1.7 (self-compiled) works, though.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 13:07:23 2011
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Thu, 14 Jul 2011 13:07:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (LOGTOOL-23) Seems to be an XNIO
 bug with the processor and JDK7
In-Reply-To: <1614389585.6632.1308581663662.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <733141577.54209.1310663243859.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

James Perkins closed LOGTOOL-23.
--------------------------------

    Resolution: Rejected


This is due to a big in OpenJDK, http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7057153.

> Seems to be an XNIO bug with the processor and JDK7
> ---------------------------------------------------
>
>                 Key: LOGTOOL-23
>                 URL: https://issues.jboss.org/browse/LOGTOOL-23
>             Project: Log Tool
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> The error appears to be in com.sun.tools.javac.files.JavacFilerManager.
> error: Cannot read org.jboss.logging.test package files, cause : java.io.FileNotFoundException: org.jboss.logging.test/ExtendedBasicLogger
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> 	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> 	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
> 	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> 	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> 	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> 	at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> 	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:613)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> 	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure
> error: Cannot read org.jboss.logging.test package files, cause : java.io.FileNotFoundException: org.jboss.logging.test/ExtendedBasicLogger
> 	at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:656)
> 	at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128)
> 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> 	... 19 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 13:07:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 14 Jul 2011 13:07:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1274) consecutive add of
 deployment does not fail/warn
In-Reply-To: <1971864514.51501.1310586623702.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2023837178.54213.1310663244002.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned AS7-1274:
-------------------------------------

    Assignee: Emanuel Muckenhuber


> consecutive add of deployment does not fail/warn 
> -------------------------------------------------
>
>                 Key: AS7-1274
>                 URL: https://issues.jboss.org/browse/AS7-1274
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Final
>            Reporter: Max Rydahl Andersen
>            Assignee: Emanuel Muckenhuber
>             Fix For: 7.0.1.Final
>
>
> using the scripts from https://github.com/maxandersen/as7scripting which simply just add contents and deploys it the following runs never fails.
> from discussion on irc it should.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 13:07:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 14 Jul 2011 13:07:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1274) consecutive add of
 deployment does not fail/warn
In-Reply-To: <1971864514.51501.1310586623702.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1505545.54217.1310663244160.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-1274:
----------------------------------

        Fix Version/s: 7.0.1.Final
    Affects Version/s: 7.0.0.Final
             Priority: Critical  (was: Major)
          Component/s: Domain Management


> consecutive add of deployment does not fail/warn 
> -------------------------------------------------
>
>                 Key: AS7-1274
>                 URL: https://issues.jboss.org/browse/AS7-1274
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.0.0.Final
>            Reporter: Max Rydahl Andersen
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>             Fix For: 7.0.1.Final
>
>
> using the scripts from https://github.com/maxandersen/as7scripting which simply just add contents and deploys it the following runs never fails.
> from discussion on irc it should.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 13:29:23 2011
From: jira-events at lists.jboss.org (Josef Wegner (JIRA))
Date: Thu, 14 Jul 2011 13:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1284) Accessing
 localhost:8080 using JBoss Web Native causes
 java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
In-Reply-To: <2087989740.53707.1310651303687.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2142548576.54248.1310664563912.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Josef Wegner updated AS7-1284:
------------------------------

    Attachment: libtcnative-1.jnilib


64bit version of Tomcat Native 1.1.21, build from http://svn.apache.org/repos/asf/tomcat/native/branches/1.1.x

> Accessing localhost:8080 using JBoss Web Native causes java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1284
>                 URL: https://issues.jboss.org/browse/AS7-1284
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>         Environment: Darwin osx-en-jwegne.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) Client VM (build 20.1-b02-384, mixed mode)
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)
>            Reporter: Josef Wegner
>            Assignee: Remy Maucherat
>            Priority: Minor
>         Attachments: libtcnative-1.jnilib
>
>
> Hi,
> accessing http://localhost:8080 using JBoss Web Native 2.0.9 (self compiled for x64 and downloaded from http://www.jboss.org/jbossweb/downloads/jboss-native-2-0-9.html for i386) causes following stack trace:
> {quote}
> 15:23:18,710 ERROR [org.apache.coyote.http11.Http11AprProtocol] (http--127.0.0.1-8080-1) Error reading request, ignored: java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> 	at org.apache.tomcat.jni.Socket.setrbb(Native Method)
> 	at org.apache.coyote.http11.InternalAprInputBuffer.setSocket(InternalAprInputBuffer.java:202)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:825)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: java.lang.ClassNotFoundException: sun.nio.ch.DirectBuffer from [Module "org.jboss.as.web:main" from local module loader @39e87719 (roots: /Users/jwegne/Tools/jboss-as-web-7.0.0.Final/modules)]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
> 	... 6 more
> {quote}
> This happens with only when using JDK 1.6 provided by Apple. OpenJDK 1.7 (self-compiled) works, though.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 13:35:23 2011
From: jira-events at lists.jboss.org (Sanne Grinovero (JIRA))
Date: Thu, 14 Jul 2011 13:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1345) JDBC_PING fails to
 initialize table in mysql
In-Reply-To: <146558224.51504.1310586863624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1832762145.54253.1310664923675.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Sanne Grinovero commented on JGRP-1345:
---------------------------------------

Hi Raul, I can't fix MySQL's default configuration, so since the default SQL fragment must be standard I see no way out other than having people need to read the error, find the documentation and fix their configuration.

{quote}The app silently fails later when it tries to insert data in tables that do not exist.{quote}
That is very bad!
I'm checking the JDBC_PING code, if it fails to write this is what should be executed:
{code}log.error("Error updating JDBC_PING table", e);{code}

Don't you have this error in your log?

I'd also remind you that having a MySQL not configured for InnoDB and not using utf8 as char sets has several consequences on your Hibernate application too, you might not have noticed yet but it's generally considered a totally broken configuration...

> JDBC_PING fails to initialize table in mysql
> --------------------------------------------
>
>                 Key: JGRP-1345
>                 URL: https://issues.jboss.org/browse/JGRP-1345
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.12
>            Reporter: Ra?l Raja Mart?nez
>            Assignee: Sanne Grinovero
>             Fix For: 2.12.2, 3.0
>
>
> JDBC_PING fails to initialize DB table for discover when executing the following SQL:
> CREATE TABLE JGROUPSPING (own_addr varchar(200) NOT NULL, cluster_name varchar(200) NOT NULL, ping_data varbinary(5000) DEFAULT NULL, PRIMARY KEY (own_addr, cluster_name) )
> The statement results in "Specified key was too long; max key length is 1000 bytes"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Thu Jul 14 13:46:23 2011
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ra=C3=BAl_Raja_Mart=C3=ADnez_=28JIRA=29?=)
Date: Thu, 14 Jul 2011 13:46:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1345) JDBC_PING fails to
 initialize table in mysql
In-Reply-To: <146558224.51504.1310586863624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1169601550.54258.1310665583765.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Ra?l Raja Mart?nez commented on JGRP-1345:
------------------------------------------

I agree with you, I think your SQL is correct, just pointing out that it may be a common problem for many people. Thanks for updating the docs.
As for the code in 2.12.0.Final this is the code for initializing the table.

 protected void attemptSchemaInitialization() {
        if (stringIsEmpty(initialize_sql)) {
            log.info("Table creation step skipped: initialize_sql property is missing");
            return;
        }
        Connection connection = getConnection();
        if (connection != null) {
            try {
                try {
                    PreparedStatement preparedStatement =
                        connection.prepareStatement(initialize_sql);
                    preparedStatement.execute();
                    log.info("Table created for JDBC_PING Discovery Protocol");
                } catch (SQLException e) {
                    if (log.isDebugEnabled()) {
                        log.debug("Could not execute initialize_sql statement; not necessarily an error.", e);
                    }
                    else {
                        //avoid printing out the stacktrace
                        log.info("Could not execute initialize_sql statement; not necessarily an error. Set to debug logging level for details.");
                    }
                }
            } finally {
                try {
                    connection.close();
                } catch (SQLException e) {
                    log.error("Error closing connection", e);
                }
            }
        }
    }

The catch statement does not print to error so the error is not apparent unless you have debug turned on.

> JDBC_PING fails to initialize table in mysql
> --------------------------------------------
>
>                 Key: JGRP-1345
>                 URL: https://issues.jboss.org/browse/JGRP-1345
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.12
>            Reporter: Ra?l Raja Mart?nez
>            Assignee: Sanne Grinovero
>             Fix For: 2.12.2, 3.0
>
>
> JDBC_PING fails to initialize DB table for discover when executing the following SQL:
> CREATE TABLE JGROUPSPING (own_addr varchar(200) NOT NULL, cluster_name varchar(200) NOT NULL, ping_data varbinary(5000) DEFAULT NULL, PRIMARY KEY (own_addr, cluster_name) )
> The statement results in "Specified key was too long; max key length is 1000 bytes"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Thu Jul 14 13:53:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 14 Jul 2011 13:53:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-627) Track component
	updates
Message-ID: <1066634417.54263.1310666003678.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Track component updates
-----------------------

                 Key: JBJCA-627
                 URL: https://issues.jboss.org/browse/JBJCA-627
             Project: IronJacamar
          Issue Type: Task
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.1.Final




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 13:55:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 14 Jul 2011 13:55:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-628) EntirePool doesn't
	clean up
Message-ID: <1193791162.54268.1310666123677.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

EntirePool doesn't clean up
---------------------------

                 Key: JBJCA-628
                 URL: https://issues.jboss.org/browse/JBJCA-628
             Project: IronJacamar
          Issue Type: Bug
          Components: Core
    Affects Versions: 1.0.0.Final
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
            Priority: Critical
             Fix For: 1.0.1.Final, 1.1.0.Alpha1


If an "EntirePool" policy or flush(true) is triggered the permits aren't cleaned up

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 13:55:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 14 Jul 2011 13:55:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-629) AvailableCount
	incorrect
Message-ID: <914405767.54269.1310666123695.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

AvailableCount incorrect
------------------------

                 Key: JBJCA-629
                 URL: https://issues.jboss.org/browse/JBJCA-629
             Project: IronJacamar
          Issue Type: Bug
          Components: Core
    Affects Versions: 1.0.0.Final
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.1.Final, 1.1.0.Alpha1


The AvailableCount statistics is incorrectly calculated and not updated in all cases

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 14:30:23 2011
From: jira-events at lists.jboss.org (Brad Davis (JIRA))
Date: Thu, 14 Jul 2011 14:30:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3141) Replace
 BinaryHeapPriorityQueue Implementation with Java's PriorityBlockingQueue
In-Reply-To: <436055328.52349.1310621003612.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1827679662.54324.1310668223657.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brad Davis commented on JBRULES-3141:
-------------------------------------

Removal and search over the heap is slow with the Java implementation.  We will need to figure out a way around this for self removal.

I will add tests for search and self removal, and will extend the BasePriorityQueue to support faster self removal.

> Replace BinaryHeapPriorityQueue Implementation with Java's PriorityBlockingQueue
> --------------------------------------------------------------------------------
>
>                 Key: JBRULES-3141
>                 URL: https://issues.jboss.org/browse/JBRULES-3141
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Brad Davis
>            Assignee: Mark Proctor
>         Attachments: BasePriorityQueue.java, BinaryHeapPriorityQueueTest.java
>
>
> Attached is a PriorityQueue implementation I wrote last night to replace our home grown implementation.  I think it must have preceded the PriorityBlockingQueue that is already part of Java 5 & 6.
> BinaryHeapPriorityQueueTest is where I plugged in this implementation.  Below are the results first running with our home grown BinaryHeapPriorityQueue, and then with the one I created, BasePriorityQueue.  There are numerous other benefits to using this as well, as it will fully implement the java.util.Collections API and therefore cleanup some other code elsewhere in our codebase.
> The result for 10000 objects inserted and retracted was: 
> BinaryHeapPriortyQueue
> elapsedEnqueue = 32
> elapsedDequeue = 294
> BasePriorityQueue
> elapsedEnqueue = 26
> elapsedDequeue = 167

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 14:32:23 2011
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Thu, 14 Jul 2011 14:32:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-3141) Replace
 BinaryHeapPriorityQueue Implementation with Java's PriorityBlockingQueue
In-Reply-To: <436055328.52349.1310621003612.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <984392788.54329.1310668343659.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Mark Proctor reassigned JBRULES-3141:
-------------------------------------

    Assignee: Brad Davis  (was: Mark Proctor)


> Replace BinaryHeapPriorityQueue Implementation with Java's PriorityBlockingQueue
> --------------------------------------------------------------------------------
>
>                 Key: JBRULES-3141
>                 URL: https://issues.jboss.org/browse/JBRULES-3141
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Brad Davis
>            Assignee: Brad Davis
>         Attachments: BasePriorityQueue.java, BinaryHeapPriorityQueueTest.java
>
>
> Attached is a PriorityQueue implementation I wrote last night to replace our home grown implementation.  I think it must have preceded the PriorityBlockingQueue that is already part of Java 5 & 6.
> BinaryHeapPriorityQueueTest is where I plugged in this implementation.  Below are the results first running with our home grown BinaryHeapPriorityQueue, and then with the one I created, BasePriorityQueue.  There are numerous other benefits to using this as well, as it will fully implement the java.util.Collections API and therefore cleanup some other code elsewhere in our codebase.
> The result for 10000 objects inserted and retracted was: 
> BinaryHeapPriortyQueue
> elapsedEnqueue = 32
> elapsedDequeue = 294
> BasePriorityQueue
> elapsedEnqueue = 26
> elapsedDequeue = 167

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 14:47:23 2011
From: jira-events at lists.jboss.org (Rajiv Mathew (JIRA))
Date: Thu, 14 Jul 2011 14:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-2227) @Startup
 @Singleton (via switchboard) should take into account transitive ENC
 dependencies before instantiating the bean
In-Reply-To: <65976238.34871.1294150758446.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <781155053.54352.1310669243886.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Rajiv Mathew commented on EJBTHREE-2227:
----------------------------------------

Hi Jaikiran,

I just noticed that AS7 has been released. Any update on whether the resolution for this issue is included in AS7 final?

> @Startup @Singleton (via switchboard) should take into account transitive ENC dependencies before instantiating the bean
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-2227
>                 URL: https://issues.jboss.org/browse/EJBTHREE-2227
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: singleton
>    Affects Versions: depchain-1.0.0-alpha-43
>         Environment: JBoss AS 6.0 Final
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>            Priority: Critical
>
> Consider the following beans:
> @Startup 
> @Singleton
> public class A
> {
>  @EJB
>  private B slsb1;
>  @PostConstruct
>  public void onConstruct()
>  {
>    slsb1.doSomething();
>  } 
> }
> @Stateless
> public class B
> {
>   @EJB
>   private C slsb2;
> }
> @Stateless
> public class C
> {
> ....
> }
> Currently, the @Startup @Singleton is instantiated when the ENC of that bean is fully invokable. However, it only waits for a populated ENC of transitive dependent bean(s). This can lead random failures with lookup. Please see the referenced forum thread for the complete details.
>  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 14:49:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 14 Jul 2011 14:49:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-2227) @Startup
 @Singleton (via switchboard) should take into account transitive ENC
 dependencies before instantiating the bean
In-Reply-To: <65976238.34871.1294150758446.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1115935200.54372.1310669363740.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on EJBTHREE-2227:
----------------------------------------

AS7 is completely different codebase and doesn't run into this issue. 

As for the fix for this issue, it's planned for AS 6.1.0

> @Startup @Singleton (via switchboard) should take into account transitive ENC dependencies before instantiating the bean
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-2227
>                 URL: https://issues.jboss.org/browse/EJBTHREE-2227
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: singleton
>    Affects Versions: depchain-1.0.0-alpha-43
>         Environment: JBoss AS 6.0 Final
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>            Priority: Critical
>
> Consider the following beans:
> @Startup 
> @Singleton
> public class A
> {
>  @EJB
>  private B slsb1;
>  @PostConstruct
>  public void onConstruct()
>  {
>    slsb1.doSomething();
>  } 
> }
> @Stateless
> public class B
> {
>   @EJB
>   private C slsb2;
> }
> @Stateless
> public class C
> {
> ....
> }
> Currently, the @Startup @Singleton is instantiated when the ENC of that bean is fully invokable. However, it only waits for a populated ENC of transitive dependent bean(s). This can lead random failures with lookup. Please see the referenced forum thread for the complete details.
>  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 14:55:32 2011
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Thu, 14 Jul 2011 14:55:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3141) Replace
 BinaryHeapPriorityQueue Implementation with Java's PriorityBlockingQueue
In-Reply-To: <436055328.52349.1310621003612.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2095525578.54404.1310669732708.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Mark Proctor commented on JBRULES-3141:
---------------------------------------

As previously mentioned we can't use the JDK PriorityQueue as random removal is search based. This makes it very slow for removing cancelled activations.

While the binary heap queue algorithm is pretty standard, reviewing the two implementations there is some very subtle differences. Our one is "1" based where as the JDK one is 0 based.  percolateUpMaxHeap  vs siftUpUsingComparator is ever so slightly different too, using shift operators instead of / etc.

My guess is you should be able to move ours to the same logic as JDK's, without copy pasting, and achieve similar results. While still being faster for random removal.

> Replace BinaryHeapPriorityQueue Implementation with Java's PriorityBlockingQueue
> --------------------------------------------------------------------------------
>
>                 Key: JBRULES-3141
>                 URL: https://issues.jboss.org/browse/JBRULES-3141
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Brad Davis
>            Assignee: Brad Davis
>         Attachments: BasePriorityQueue.java, BinaryHeapPriorityQueueTest.java
>
>
> Attached is a PriorityQueue implementation I wrote last night to replace our home grown implementation.  I think it must have preceded the PriorityBlockingQueue that is already part of Java 5 & 6.
> BinaryHeapPriorityQueueTest is where I plugged in this implementation.  Below are the results first running with our home grown BinaryHeapPriorityQueue, and then with the one I created, BasePriorityQueue.  There are numerous other benefits to using this as well, as it will fully implement the java.util.Collections API and therefore cleanup some other code elsewhere in our codebase.
> The result for 10000 objects inserted and retracted was: 
> BinaryHeapPriortyQueue
> elapsedEnqueue = 32
> elapsedDequeue = 294
> BasePriorityQueue
> elapsedEnqueue = 26
> elapsedDequeue = 167

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 15:40:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Thu, 14 Jul 2011 15:40:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1260) JGroups subsystem
 fails to setup some protocol stacks.
In-Reply-To: <1568744513.48245.1310478143759.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <457309889.54442.1310672423863.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro commented on AS7-1260:
-----------------------------------

Correct.  I've fixed this in a subsequent commit, currently awaiting merge into master:
https://github.com/jbossas/jboss-as/commit/2efc0479e040dfabeb8ded9a9e8fde99c6fccbd7

> JGroups subsystem fails to setup some protocol stacks.
> ------------------------------------------------------
>
>                 Key: AS7-1260
>                 URL: https://issues.jboss.org/browse/AS7-1260
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.Final
>            Reporter: Trustin Lee
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 7.0.1.Final, 7.1.0.Alpha1
>
>
> After upgrading from AS 7.0.0.CR1 to AS 7.0.0.Final, I started to see an exception raised by org.jboss.as.clustering.jgroups.JChannelFactory:
> {code}
> 22:11:54,040 ERROR [stderr] (MSC service thread 1-1) java.lang.IllegalArgumentException: org.jgroups.ChannelException: unable to setup the protocol stack
> 22:11:54,040 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.ChannelProvider.getJGroupsChannel(ChannelProvider.java:71)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:273)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:226)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:254)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:148)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 22:11:54,041 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at java.lang.reflect.Method.invoke(Method.java:597)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:172)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:918)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:711)
> 22:11:54,042 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:611)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:176)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:171)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.CacheImpl.start(CacheImpl.java:366)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:559)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:455)
> 22:11:54,043 ERROR [stderr] (MSC service thread 1-1) 	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:479)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:84)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:73)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:73)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> 22:11:54,044 ERROR [stderr] (MSC service thread 1-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at java.lang.Thread.run(Thread.java:680)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) Caused by: org.jgroups.ChannelException: unable to setup the protocol stack
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.init(JChannel.java:1728)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.<init>(JChannel.java:249)
> 22:11:54,045 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.jgroups.JChannelFactory$JChannel.<init>(JChannelFactory.java:269)
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:69)
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jboss.as.clustering.infinispan.ChannelProvider.getJGroupsChannel(ChannelProvider.java:67)
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	... 26 more
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) Caused by: java.lang.IllegalArgumentException: the following properties in PING are not recognized: {bind_addr=192.168.0.196}
> 22:11:54,046 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.createLayer(Configurator.java:460)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.createProtocols(Configurator.java:393)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:88)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:55)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:534)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	at org.jgroups.JChannel.init(JChannel.java:1725)
> 22:11:54,047 ERROR [stderr] (MSC service thread 1-1) 	... 30 more
> {code}
> (Actually, the exception was being swallowed by Infinispan, so I had to modify the source code in Infinispan.)
> Reverting back only the JGroups subsystem to 7.0.0.CR1 fixes the problem for UDP stack.  TCP stack still fails when configuring MPING:
> {code}
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) Caused by: java.lang.IllegalArgumentException: the following properties in MPING are not recognized: {start_port=0}
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.createLayer(Configurator.java:460)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.createProtocols(Configurator.java:393)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:88)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:55)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:534)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	at org.jgroups.JChannel.init(JChannel.java:1725)
> 23:40:07,623 ERROR [stderr] (MSC service thread 1-8) 	... 30 more
> {code}
> The offending subsystem configuration is:
> {code}
>         <subsystem xmlns="urn:jboss:domain:jgroups:1.0" default-stack="udp">
>             <stack name="udp">
>                 <transport type="UDP"
>                            socket-binding="jgroups-udp"
>                            default-executor="jgroups"
>                            oob-executor="jgroups-oob"
>                            timer-executor="jgroups-timer"/>
>                 <protocol type="PING"/>
>                 <protocol type="MERGE2"/>
>                 <protocol type="FD_SOCK"/>
>                 <protocol type="FD"/>
>                 <protocol type="VERIFY_SUSPECT"/>
>                 <protocol type="BARRIER"/>
>                 <protocol type="pbcast.NAKACK"/>
>                 <protocol type="UNICAST"/>
>                 <protocol type="pbcast.STABLE"/>
>                 <protocol type="VIEW_SYNC"/>
>                 <protocol type="pbcast.GMS"/>
>                 <protocol type="UFC"/>
>                 <protocol type="MFC"/>
>                 <protocol type="FRAG2"/>
>                 <protocol type="pbcast.STREAMING_STATE_TRANSFER"/>
>                 <protocol type="pbcast.FLUSH"/>
>             </stack>
>             <stack name="tcp">
>                 <transport type="TCP"
>                            socket-binding="jgroups-tcp"
>                            default-executor="jgroups"
>                            oob-executor="jgroups-oob"
>                            timer-executor="jgroups-timer"/>
>                 <protocol type="MPING" socket-binding="jgroups-mping"/>
>                 <protocol type="MERGE2"/>
>                 <protocol type="FD_SOCK"/>
>                 <protocol type="FD"/>
>                 <protocol type="VERIFY_SUSPECT"/>
>                 <protocol type="BARRIER"/>
>                 <protocol type="pbcast.NAKACK"/>
>                 <protocol type="UNICAST"/>
>                 <protocol type="pbcast.STABLE"/>
>                 <protocol type="VIEW_SYNC"/>
>                 <protocol type="pbcast.GMS"/>
>                 <protocol type="UFC"/>
>                 <protocol type="MFC"/>
>                 <protocol type="FRAG2"/>
>                 <protocol type="pbcast.STREAMING_STATE_TRANSFER"/>
>                 <protocol type="pbcast.FLUSH"/>
>             </stack>
>         </subsystem>
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 16:22:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Thu, 14 Jul 2011 16:22:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBVFS-175) NPE on shutdown
Message-ID: <1343933426.54490.1310674943605.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

NPE on shutdown
---------------

                 Key: JBVFS-175
                 URL: https://issues.jboss.org/browse/JBVFS-175
             Project: JBoss VFS
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 3.0.1.GA
            Reporter: David Lloyd
            Assignee: John Bailey
             Fix For: 3.0.2.CR1, 3.1.0.CR1


See AS7-1288 for the sequence of events.  The NPE is in DeleteTask in TempFileProvider.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 17:15:24 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Thu, 14 Jul 2011 17:15:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1275)
 ClassNotFoundException When Restarting Node In Cluster with Distributable
 App Deployed
In-Reply-To: <908967862.51711.1310595683786.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1988148320.54545.1310678124243.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro updated AS7-1275:
------------------------------

         Assignee: Paul Ferraro
    Fix Version/s: 7.0.1.Final
                   7.1.0.Alpha1
      Component/s: Clustering


> ClassNotFoundException When Restarting Node In Cluster with Distributable App Deployed
> --------------------------------------------------------------------------------------
>
>                 Key: AS7-1275
>                 URL: https://issues.jboss.org/browse/AS7-1275
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.Final
>            Reporter: Benjamin Browning
>            Assignee: Paul Ferraro
>             Fix For: 7.0.1.Final, 7.1.0.Alpha1
>
>
> When restarting a node in a cluster with a <distributable/> app deployed I get the below stacktrace. See the Steps to Reproduce for the steps taken leading up to this stacktrace.
> bbrowning at bbrowning-mbp:~/Downloads/jboss-as-web-7.0.0.Final$ bin/standalone.sh -server-config standalone-ha-2.xml -Djboss.server.data.dir=/tmp/node2 -Djgroups.bind_addr=127.0.0.2
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /Users/bbrowning/Downloads/jboss-as-web-7.0.0.Final
>   JAVA: /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/bin/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
> =========================================================================
> 16:48:00,839 INFO  [org.jboss.modules] JBoss Modules version 1.0.1.GA
> 16:48:01,187 INFO  [org.jboss.msc] JBoss MSC version 1.0.0.GA
> 16:48:01,253 INFO  [org.jboss.as] JBoss AS 7.0.0.Final "Lightning" starting
> 16:48:02,465 INFO  [org.jboss.as] creating http management service using network interface (management) port (9990) securePort (-1)
> 16:48:02,474 INFO  [org.jboss.as.logging] Removing bootstrap log handlers
> 16:48:02,501 INFO  [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying JDBC-compliant driver class org.h2.Driver (version 1.2)
> 16:48:02,517 INFO  [org.jboss.as.clustering.infinispan.subsystem] (Controller Boot Thread) Activating Infinispan subsystem.
> 16:48:02,658 INFO  [org.jboss.as.clustering.jgroups.subsystem] (Controller Boot Thread) Activating JGroups subsystem.
> 16:48:02,695 INFO  [org.jboss.as.osgi] (Controller Boot Thread) Activating OSGi Subsystem
> 16:48:02,714 INFO  [org.jboss.as.naming] (Controller Boot Thread) Activating Naming Subsystem
> 16:48:02,726 INFO  [org.jboss.as.naming] (MSC service thread 1-6) Starting Naming Service 
> 16:48:02,737 INFO  [org.jboss.as.security] (Controller Boot Thread) Activating Security Subsystem
> 16:48:02,744 INFO  [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 3.2.0.Beta2
> 16:48:02,757 INFO  [org.xnio] (MSC service thread 1-2) XNIO Version 3.0.0.Beta3
> 16:48:02,773 INFO  [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.0.0.Beta3
> 16:48:02,910 INFO  [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-7) 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
> 16:48:02,938 INFO  [org.jboss.as.ee] (Controller Boot Thread) Activating EE subsystem
> 16:48:02,943 INFO  [org.jboss.as.jmx.JMXConnectorService] (MSC service thread 1-4) Starting remote JMX connector
> 16:48:02,986 INFO  [org.jboss.as.modcluster] (MSC service thread 1-8) Mod_cluster uses default load balancer provider
> 16:48:02,990 INFO  [org.jboss.as.remoting] (MSC service thread 1-1) Listening on /127.0.0.2:9999
> 16:48:03,089 INFO  [org.jboss.modcluster.ModClusterService] (MSC service thread 1-8) Initializing mod_cluster 1.1.2.Final
> 16:48:03,095 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-6) Starting Coyote HTTP/1.1 on http--127.0.0.2-8080
> 16:48:03,328 INFO  [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (MSC service thread 1-8) Listening to proxy advertisements on 224.0.1.105:23364
> 16:48:03,371 INFO  [org.jboss.as.connector] (MSC service thread 1-4) Starting JCA Subsystem (JBoss IronJacamar 1.0.0.CR2)
> 16:48:03,465 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) Bound data source [java:jboss/datasources/ExampleDS]
> 16:48:03,964 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) Starting deployment of "make-love-not.war"
> 16:48:03,972 INFO  [org.jboss.as.deployment] (MSC service thread 1-2) Started FileSystemDeploymentService for directory /Users/bbrowning/Downloads/jboss-as-web-7.0.0.Final/standalone/deployments
> 16:48:04,665 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN00078: Starting JGroups Channel
> 16:48:04,669 INFO  [org.jgroups.JChannel] (MSC service thread 1-5) JGroups version: 2.12.1.Final
> 16:48:04,733 ERROR [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN00084: Errors instantiating [org.jboss.as.clustering.infinispan.ChannelProvider]!  Not using a channel lookup.
> 16:48:04,734 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN00088: Unable to use any JGroups configuration mechanisms provided in properties {channelLookup=org.jboss.as.clustering.infinispan.ChannelProvider, channel-factory=org.jboss.as.clustering.jgroups.JChannelFactory at 34e5307e, id=bbrowning-mbp-web}.  Using default JGroups configuration!
> 16:48:04,740 INFO  [org.jgroups.JChannel] (MSC service thread 1-5) JGroups version: 2.12.1.Final
> 16:48:04,928 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-5) receive buffer of socket java.net.DatagramSocket at 1d1d2b8 was set to 20MB, but the OS only allocated 65.51KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 16:48:04,928 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-5) receive buffer of socket java.net.MulticastSocket at 76612ef6 was set to 25MB, but the OS only allocated 65.51KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 16:48:05,021 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN00094: Received new cluster view: [bbrowning-mbp-29051|3] [bbrowning-mbp-29051, bbrowning-mbp-40805]
> 16:48:05,069 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN00079: Cache local address is bbrowning-mbp-40805, physical addresses are [127.0.0.2:50060]
> 16:48:05,069 INFO  [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-5) ISPN00128: Infinispan version: Infinispan 'Pagoa' 5.0.0.CR7
> 16:48:05,128 INFO  [org.infinispan.remoting.rpc.RpcManagerImpl] (MSC service thread 1-5) ISPN00074: Trying to fetch state from bbrowning-mbp-29051
> 16:48:05,240 INFO  [org.infinispan.remoting.rpc.RpcManagerImpl] (MSC service thread 1-5) ISPN00076: Successfully retrieved and applied state from bbrowning-mbp-29051
> 16:48:05,242 INFO  [org.infinispan.factories.ComponentRegistry] (MSC service thread 1-5) ISPN00128: Infinispan version: Infinispan 'Pagoa' 5.0.0.CR7
> 16:48:05,244 INFO  [org.jboss.as.clustering.infinispan.subsystem] (MSC service thread 1-5) Started repl cache from web container
> 16:48:05,276 INFO  [org.jboss.as.clustering.CoreGroupCommunicationService.web] (MSC service thread 1-4) Number of cluster members: 2
> 16:48:05,298 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (MSC service thread 1-4) ISPN00136: Execution error: org.infinispan.CacheException: Unable to unmarshall value
>         at org.infinispan.marshall.MarshalledValue.deserialize0(MarshalledValue.java:148)
>         at org.infinispan.marshall.MarshalledValue.deserialize(MarshalledValue.java:132)
>         at org.infinispan.marshall.MarshalledValue.get(MarshalledValue.java:213)
>         at org.infinispan.interceptors.MarshalledValueInterceptor.visitKeySetCommand(MarshalledValueInterceptor.java:204)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:99)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:64)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:77)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:274)
>         at org.infinispan.CacheImpl.keySet(CacheImpl.java:261)
>         at org.infinispan.AbstractDelegatingCache.keySet(AbstractDelegatingCache.java:261)
>         at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getSessionIds(DistributedCacheManager.java:413)
>         at org.jboss.as.web.session.DistributableSessionManager.initializeUnloadedSessions(DistributableSessionManager.java:299) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.as.web.session.DistributableSessionManager.start(DistributableSessionManager.java:201) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.apache.catalina.core.ContainerBase.setManager(ContainerBase.java:459) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.JBossContextConfig.processWebMetaData(JBossContextConfig.java:278) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.JBossContextConfig.applicationWebConfig(JBossContextConfig.java:166) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:417) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:182) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.JBossContextConfig.lifecycleEvent(JBossContextConfig.java:159) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:115) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.core.StandardContext.start(StandardContext.java:3766) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
>         at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
>         at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: java.lang.ClassNotFoundException: org.jboss.as.clustering.web.infinispan.DistributedCacheManagerFactory$SessionKeyImpl from [Module "deployment.make-love-not.war:main" from Service Module Loader]
>         at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
>         at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
>         at java.lang.Class.forName0(Native Method) [:1.6.0_26]
>         at java.lang.Class.forName(Class.java:247) [:1.6.0_26]
>         at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
>         at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:888)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1200)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
>         at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
>         at org.infinispan.marshall.jboss.GenericJBossMarshaller.objectFromObjectStream(GenericJBossMarshaller.java:191)
>         at org.infinispan.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:122)
>         at org.infinispan.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:98)
>         at org.infinispan.marshall.MarshalledValue.deserialize0(MarshalledValue.java:143)
>         ... 41 more
> 16:48:05,306 ERROR [org.apache.catalina.session.ManagerBase] (MSC service thread 1-4) Unable to start manager.: org.infinispan.CacheException: Unable to unmarshall value
>         at org.infinispan.marshall.MarshalledValue.deserialize0(MarshalledValue.java:148)
>         at org.infinispan.marshall.MarshalledValue.deserialize(MarshalledValue.java:132)
>         at org.infinispan.marshall.MarshalledValue.get(MarshalledValue.java:213)
>         at org.infinispan.interceptors.MarshalledValueInterceptor.visitKeySetCommand(MarshalledValueInterceptor.java:204)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:99)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:64)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:77)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:274)
>         at org.infinispan.CacheImpl.keySet(CacheImpl.java:261)
>         at org.infinispan.AbstractDelegatingCache.keySet(AbstractDelegatingCache.java:261)
>         at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getSessionIds(DistributedCacheManager.java:413)
>         at org.jboss.as.web.session.DistributableSessionManager.initializeUnloadedSessions(DistributableSessionManager.java:299) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.as.web.session.DistributableSessionManager.start(DistributableSessionManager.java:201) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.apache.catalina.core.ContainerBase.setManager(ContainerBase.java:459) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.JBossContextConfig.processWebMetaData(JBossContextConfig.java:278) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.JBossContextConfig.applicationWebConfig(JBossContextConfig.java:166) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:417) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:182) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.JBossContextConfig.lifecycleEvent(JBossContextConfig.java:159) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:115) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.core.StandardContext.start(StandardContext.java:3766) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
>         at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
>         at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: java.lang.ClassNotFoundException: org.jboss.as.clustering.web.infinispan.DistributedCacheManagerFactory$SessionKeyImpl from [Module "deployment.make-love-not.war:main" from Service Module Loader]
>         at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
>         at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
>         at java.lang.Class.forName0(Native Method) [:1.6.0_26]
>         at java.lang.Class.forName(Class.java:247) [:1.6.0_26]
>         at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
>         at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:888)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1200)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
>         at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
>         at org.infinispan.marshall.jboss.GenericJBossMarshaller.objectFromObjectStream(GenericJBossMarshaller.java:191)
>         at org.infinispan.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:122)
>         at org.infinispan.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:98)
>         at org.infinispan.marshall.MarshalledValue.deserialize0(MarshalledValue.java:143)
>         ... 41 more
> 16:48:05,313 ERROR [org.apache.catalina.core.ContainerBase] (MSC service thread 1-4) ContainerBase.setManager: start: : LifecycleException:  org.infinispan.CacheException: Unable to unmarshall value
>         at org.jboss.as.web.session.DistributableSessionManager.start(DistributableSessionManager.java:213) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.apache.catalina.core.ContainerBase.setManager(ContainerBase.java:459) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.JBossContextConfig.processWebMetaData(JBossContextConfig.java:278) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.JBossContextConfig.applicationWebConfig(JBossContextConfig.java:166) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:417) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:182) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.JBossContextConfig.lifecycleEvent(JBossContextConfig.java:159) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:115) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.core.StandardContext.start(StandardContext.java:3766) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
>         at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
>         at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> 16:48:05,385 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (MSC service thread 1-4) ISPN00136: Execution error: org.infinispan.CacheException: Unable to unmarshall value
>         at org.infinispan.marshall.MarshalledValue.deserialize0(MarshalledValue.java:148)
>         at org.infinispan.marshall.MarshalledValue.deserialize(MarshalledValue.java:132)
>         at org.infinispan.marshall.MarshalledValue.get(MarshalledValue.java:213)
>         at org.infinispan.interceptors.MarshalledValueInterceptor.visitKeySetCommand(MarshalledValueInterceptor.java:204)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:99)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:64)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:77)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:274)
>         at org.infinispan.CacheImpl.keySet(CacheImpl.java:261)
>         at org.infinispan.AbstractDelegatingCache.keySet(AbstractDelegatingCache.java:261)
>         at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getSessionIds(DistributedCacheManager.java:413)
>         at org.jboss.as.web.session.DistributableSessionManager.initializeUnloadedSessions(DistributableSessionManager.java:299) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.as.web.session.DistributableSessionManager.start(DistributableSessionManager.java:201) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.apache.catalina.core.StandardContext.start(StandardContext.java:3830) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
>         at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
>         at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: java.lang.ClassNotFoundException: org.jboss.as.clustering.web.infinispan.DistributedCacheManagerFactory$SessionKeyImpl from [Module "deployment.make-love-not.war:main" from Service Module Loader]
>         at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
>         at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
>         at java.lang.Class.forName0(Native Method) [:1.6.0_26]
>         at java.lang.Class.forName(Class.java:247) [:1.6.0_26]
>         at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
>         at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:888)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1200)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
>         at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
>         at org.infinispan.marshall.jboss.GenericJBossMarshaller.objectFromObjectStream(GenericJBossMarshaller.java:191)
>         at org.infinispan.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:122)
>         at org.infinispan.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:98)
>         at org.infinispan.marshall.MarshalledValue.deserialize0(MarshalledValue.java:143)
>         ... 34 more
> 16:48:05,392 ERROR [org.jboss.as.web.session.DistributableSessionManager.make-love-not] (MSC service thread 1-4) Unable to start manager.: org.infinispan.CacheException: Unable to unmarshall value
>         at org.infinispan.marshall.MarshalledValue.deserialize0(MarshalledValue.java:148)
>         at org.infinispan.marshall.MarshalledValue.deserialize(MarshalledValue.java:132)
>         at org.infinispan.marshall.MarshalledValue.get(MarshalledValue.java:213)
>         at org.infinispan.interceptors.MarshalledValueInterceptor.visitKeySetCommand(MarshalledValueInterceptor.java:204)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:99)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:64)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:77)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:274)
>         at org.infinispan.CacheImpl.keySet(CacheImpl.java:261)
>         at org.infinispan.AbstractDelegatingCache.keySet(AbstractDelegatingCache.java:261)
>         at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getSessionIds(DistributedCacheManager.java:413)
>         at org.jboss.as.web.session.DistributableSessionManager.initializeUnloadedSessions(DistributableSessionManager.java:299) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.as.web.session.DistributableSessionManager.start(DistributableSessionManager.java:201) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.apache.catalina.core.StandardContext.start(StandardContext.java:3830) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
>         at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
>         at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: java.lang.ClassNotFoundException: org.jboss.as.clustering.web.infinispan.DistributedCacheManagerFactory$SessionKeyImpl from [Module "deployment.make-love-not.war:main" from Service Module Loader]
>         at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
>         at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
>         at java.lang.Class.forName0(Native Method) [:1.6.0_26]
>         at java.lang.Class.forName(Class.java:247) [:1.6.0_26]
>         at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
>         at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:888)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1200)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
>         at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
>         at org.infinispan.marshall.jboss.GenericJBossMarshaller.objectFromObjectStream(GenericJBossMarshaller.java:191)
>         at org.infinispan.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:122)
>         at org.infinispan.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:98)
>         at org.infinispan.marshall.MarshalledValue.deserialize0(MarshalledValue.java:143)
>         ... 34 more
> 16:48:05,398 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-4) Context [/make-love-not] startup failed due to previous errors: LifecycleException:  org.infinispan.CacheException: Unable to unmarshall value
>         at org.jboss.as.web.session.DistributableSessionManager.start(DistributableSessionManager.java:213) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.apache.catalina.core.StandardContext.start(StandardContext.java:3830) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
>         at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
>         at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> 16:48:05,399 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-4) Context [/make-love-not] startup failed due to previous errors
> 16:48:05,400 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-4) Exception during cleanup after start failed: java.lang.NullPointerException
>         at org.jboss.as.web.session.DistributableSessionManager.stop(DistributableSessionManager.java:460)
>         at org.apache.catalina.core.StandardContext.stop(StandardContext.java:3966)
>         at org.apache.catalina.core.StandardContext.start(StandardContext.java:3888)
>         at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70)
>         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_26]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
>         at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> 16:48:05,402 INFO  [org.apache.catalina.core.ContainerBase] (MSC service thread 1-4) Container org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/make-love-not].[jsp] has not been started
> 16:48:05,402 INFO  [org.apache.catalina.core.ContainerBase] (MSC service thread 1-4) Container org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/make-love-not].[default] has not been started
> 16:48:05,420 INFO  [org.jboss.web] (MSC service thread 1-4) registering web context: /make-love-not
> 16:48:05,430 INFO  [org.jboss.as.server.controller] (Controller Boot Thread) Deployed "make-love-not.war"
> 16:48:05,438 INFO  [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.0.Final "Lightning" started in 4906ms - Started 126 of 204 services (78 services are passive or on-demand)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 17:15:24 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Thu, 14 Jul 2011 17:15:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1275)
 ClassNotFoundException When Restarting Node In Cluster with Distributable
 App Deployed
In-Reply-To: <908967862.51711.1310595683786.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2110417935.54547.1310678124364.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro resolved AS7-1275.
-------------------------------

    Resolution: Done


> ClassNotFoundException When Restarting Node In Cluster with Distributable App Deployed
> --------------------------------------------------------------------------------------
>
>                 Key: AS7-1275
>                 URL: https://issues.jboss.org/browse/AS7-1275
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.Final
>            Reporter: Benjamin Browning
>            Assignee: Paul Ferraro
>             Fix For: 7.0.1.Final, 7.1.0.Alpha1
>
>
> When restarting a node in a cluster with a <distributable/> app deployed I get the below stacktrace. See the Steps to Reproduce for the steps taken leading up to this stacktrace.
> bbrowning at bbrowning-mbp:~/Downloads/jboss-as-web-7.0.0.Final$ bin/standalone.sh -server-config standalone-ha-2.xml -Djboss.server.data.dir=/tmp/node2 -Djgroups.bind_addr=127.0.0.2
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /Users/bbrowning/Downloads/jboss-as-web-7.0.0.Final
>   JAVA: /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/bin/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
> =========================================================================
> 16:48:00,839 INFO  [org.jboss.modules] JBoss Modules version 1.0.1.GA
> 16:48:01,187 INFO  [org.jboss.msc] JBoss MSC version 1.0.0.GA
> 16:48:01,253 INFO  [org.jboss.as] JBoss AS 7.0.0.Final "Lightning" starting
> 16:48:02,465 INFO  [org.jboss.as] creating http management service using network interface (management) port (9990) securePort (-1)
> 16:48:02,474 INFO  [org.jboss.as.logging] Removing bootstrap log handlers
> 16:48:02,501 INFO  [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying JDBC-compliant driver class org.h2.Driver (version 1.2)
> 16:48:02,517 INFO  [org.jboss.as.clustering.infinispan.subsystem] (Controller Boot Thread) Activating Infinispan subsystem.
> 16:48:02,658 INFO  [org.jboss.as.clustering.jgroups.subsystem] (Controller Boot Thread) Activating JGroups subsystem.
> 16:48:02,695 INFO  [org.jboss.as.osgi] (Controller Boot Thread) Activating OSGi Subsystem
> 16:48:02,714 INFO  [org.jboss.as.naming] (Controller Boot Thread) Activating Naming Subsystem
> 16:48:02,726 INFO  [org.jboss.as.naming] (MSC service thread 1-6) Starting Naming Service 
> 16:48:02,737 INFO  [org.jboss.as.security] (Controller Boot Thread) Activating Security Subsystem
> 16:48:02,744 INFO  [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 3.2.0.Beta2
> 16:48:02,757 INFO  [org.xnio] (MSC service thread 1-2) XNIO Version 3.0.0.Beta3
> 16:48:02,773 INFO  [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.0.0.Beta3
> 16:48:02,910 INFO  [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-7) 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
> 16:48:02,938 INFO  [org.jboss.as.ee] (Controller Boot Thread) Activating EE subsystem
> 16:48:02,943 INFO  [org.jboss.as.jmx.JMXConnectorService] (MSC service thread 1-4) Starting remote JMX connector
> 16:48:02,986 INFO  [org.jboss.as.modcluster] (MSC service thread 1-8) Mod_cluster uses default load balancer provider
> 16:48:02,990 INFO  [org.jboss.as.remoting] (MSC service thread 1-1) Listening on /127.0.0.2:9999
> 16:48:03,089 INFO  [org.jboss.modcluster.ModClusterService] (MSC service thread 1-8) Initializing mod_cluster 1.1.2.Final
> 16:48:03,095 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-6) Starting Coyote HTTP/1.1 on http--127.0.0.2-8080
> 16:48:03,328 INFO  [org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl] (MSC service thread 1-8) Listening to proxy advertisements on 224.0.1.105:23364
> 16:48:03,371 INFO  [org.jboss.as.connector] (MSC service thread 1-4) Starting JCA Subsystem (JBoss IronJacamar 1.0.0.CR2)
> 16:48:03,465 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) Bound data source [java:jboss/datasources/ExampleDS]
> 16:48:03,964 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) Starting deployment of "make-love-not.war"
> 16:48:03,972 INFO  [org.jboss.as.deployment] (MSC service thread 1-2) Started FileSystemDeploymentService for directory /Users/bbrowning/Downloads/jboss-as-web-7.0.0.Final/standalone/deployments
> 16:48:04,665 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN00078: Starting JGroups Channel
> 16:48:04,669 INFO  [org.jgroups.JChannel] (MSC service thread 1-5) JGroups version: 2.12.1.Final
> 16:48:04,733 ERROR [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN00084: Errors instantiating [org.jboss.as.clustering.infinispan.ChannelProvider]!  Not using a channel lookup.
> 16:48:04,734 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN00088: Unable to use any JGroups configuration mechanisms provided in properties {channelLookup=org.jboss.as.clustering.infinispan.ChannelProvider, channel-factory=org.jboss.as.clustering.jgroups.JChannelFactory at 34e5307e, id=bbrowning-mbp-web}.  Using default JGroups configuration!
> 16:48:04,740 INFO  [org.jgroups.JChannel] (MSC service thread 1-5) JGroups version: 2.12.1.Final
> 16:48:04,928 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-5) receive buffer of socket java.net.DatagramSocket at 1d1d2b8 was set to 20MB, but the OS only allocated 65.51KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 16:48:04,928 WARNING [org.jgroups.protocols.UDP] (MSC service thread 1-5) receive buffer of socket java.net.MulticastSocket at 76612ef6 was set to 25MB, but the OS only allocated 65.51KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
> 16:48:05,021 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN00094: Received new cluster view: [bbrowning-mbp-29051|3] [bbrowning-mbp-29051, bbrowning-mbp-40805]
> 16:48:05,069 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN00079: Cache local address is bbrowning-mbp-40805, physical addresses are [127.0.0.2:50060]
> 16:48:05,069 INFO  [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-5) ISPN00128: Infinispan version: Infinispan 'Pagoa' 5.0.0.CR7
> 16:48:05,128 INFO  [org.infinispan.remoting.rpc.RpcManagerImpl] (MSC service thread 1-5) ISPN00074: Trying to fetch state from bbrowning-mbp-29051
> 16:48:05,240 INFO  [org.infinispan.remoting.rpc.RpcManagerImpl] (MSC service thread 1-5) ISPN00076: Successfully retrieved and applied state from bbrowning-mbp-29051
> 16:48:05,242 INFO  [org.infinispan.factories.ComponentRegistry] (MSC service thread 1-5) ISPN00128: Infinispan version: Infinispan 'Pagoa' 5.0.0.CR7
> 16:48:05,244 INFO  [org.jboss.as.clustering.infinispan.subsystem] (MSC service thread 1-5) Started repl cache from web container
> 16:48:05,276 INFO  [org.jboss.as.clustering.CoreGroupCommunicationService.web] (MSC service thread 1-4) Number of cluster members: 2
> 16:48:05,298 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (MSC service thread 1-4) ISPN00136: Execution error: org.infinispan.CacheException: Unable to unmarshall value
>         at org.infinispan.marshall.MarshalledValue.deserialize0(MarshalledValue.java:148)
>         at org.infinispan.marshall.MarshalledValue.deserialize(MarshalledValue.java:132)
>         at org.infinispan.marshall.MarshalledValue.get(MarshalledValue.java:213)
>         at org.infinispan.interceptors.MarshalledValueInterceptor.visitKeySetCommand(MarshalledValueInterceptor.java:204)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:99)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:64)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:77)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:274)
>         at org.infinispan.CacheImpl.keySet(CacheImpl.java:261)
>         at org.infinispan.AbstractDelegatingCache.keySet(AbstractDelegatingCache.java:261)
>         at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getSessionIds(DistributedCacheManager.java:413)
>         at org.jboss.as.web.session.DistributableSessionManager.initializeUnloadedSessions(DistributableSessionManager.java:299) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.as.web.session.DistributableSessionManager.start(DistributableSessionManager.java:201) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.apache.catalina.core.ContainerBase.setManager(ContainerBase.java:459) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.JBossContextConfig.processWebMetaData(JBossContextConfig.java:278) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.JBossContextConfig.applicationWebConfig(JBossContextConfig.java:166) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:417) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:182) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.JBossContextConfig.lifecycleEvent(JBossContextConfig.java:159) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:115) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.core.StandardContext.start(StandardContext.java:3766) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
>         at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
>         at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: java.lang.ClassNotFoundException: org.jboss.as.clustering.web.infinispan.DistributedCacheManagerFactory$SessionKeyImpl from [Module "deployment.make-love-not.war:main" from Service Module Loader]
>         at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
>         at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
>         at java.lang.Class.forName0(Native Method) [:1.6.0_26]
>         at java.lang.Class.forName(Class.java:247) [:1.6.0_26]
>         at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
>         at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:888)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1200)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
>         at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
>         at org.infinispan.marshall.jboss.GenericJBossMarshaller.objectFromObjectStream(GenericJBossMarshaller.java:191)
>         at org.infinispan.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:122)
>         at org.infinispan.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:98)
>         at org.infinispan.marshall.MarshalledValue.deserialize0(MarshalledValue.java:143)
>         ... 41 more
> 16:48:05,306 ERROR [org.apache.catalina.session.ManagerBase] (MSC service thread 1-4) Unable to start manager.: org.infinispan.CacheException: Unable to unmarshall value
>         at org.infinispan.marshall.MarshalledValue.deserialize0(MarshalledValue.java:148)
>         at org.infinispan.marshall.MarshalledValue.deserialize(MarshalledValue.java:132)
>         at org.infinispan.marshall.MarshalledValue.get(MarshalledValue.java:213)
>         at org.infinispan.interceptors.MarshalledValueInterceptor.visitKeySetCommand(MarshalledValueInterceptor.java:204)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:99)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:64)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:77)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:274)
>         at org.infinispan.CacheImpl.keySet(CacheImpl.java:261)
>         at org.infinispan.AbstractDelegatingCache.keySet(AbstractDelegatingCache.java:261)
>         at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getSessionIds(DistributedCacheManager.java:413)
>         at org.jboss.as.web.session.DistributableSessionManager.initializeUnloadedSessions(DistributableSessionManager.java:299) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.as.web.session.DistributableSessionManager.start(DistributableSessionManager.java:201) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.apache.catalina.core.ContainerBase.setManager(ContainerBase.java:459) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.JBossContextConfig.processWebMetaData(JBossContextConfig.java:278) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.JBossContextConfig.applicationWebConfig(JBossContextConfig.java:166) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:417) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:182) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.JBossContextConfig.lifecycleEvent(JBossContextConfig.java:159) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:115) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.core.StandardContext.start(StandardContext.java:3766) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
>         at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
>         at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: java.lang.ClassNotFoundException: org.jboss.as.clustering.web.infinispan.DistributedCacheManagerFactory$SessionKeyImpl from [Module "deployment.make-love-not.war:main" from Service Module Loader]
>         at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
>         at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
>         at java.lang.Class.forName0(Native Method) [:1.6.0_26]
>         at java.lang.Class.forName(Class.java:247) [:1.6.0_26]
>         at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
>         at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:888)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1200)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
>         at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
>         at org.infinispan.marshall.jboss.GenericJBossMarshaller.objectFromObjectStream(GenericJBossMarshaller.java:191)
>         at org.infinispan.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:122)
>         at org.infinispan.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:98)
>         at org.infinispan.marshall.MarshalledValue.deserialize0(MarshalledValue.java:143)
>         ... 41 more
> 16:48:05,313 ERROR [org.apache.catalina.core.ContainerBase] (MSC service thread 1-4) ContainerBase.setManager: start: : LifecycleException:  org.infinispan.CacheException: Unable to unmarshall value
>         at org.jboss.as.web.session.DistributableSessionManager.start(DistributableSessionManager.java:213) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.apache.catalina.core.ContainerBase.setManager(ContainerBase.java:459) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.JBossContextConfig.processWebMetaData(JBossContextConfig.java:278) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.JBossContextConfig.applicationWebConfig(JBossContextConfig.java:166) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:417) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:182) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.JBossContextConfig.lifecycleEvent(JBossContextConfig.java:159) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:115) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.core.StandardContext.start(StandardContext.java:3766) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
>         at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
>         at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> 16:48:05,385 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (MSC service thread 1-4) ISPN00136: Execution error: org.infinispan.CacheException: Unable to unmarshall value
>         at org.infinispan.marshall.MarshalledValue.deserialize0(MarshalledValue.java:148)
>         at org.infinispan.marshall.MarshalledValue.deserialize(MarshalledValue.java:132)
>         at org.infinispan.marshall.MarshalledValue.get(MarshalledValue.java:213)
>         at org.infinispan.interceptors.MarshalledValueInterceptor.visitKeySetCommand(MarshalledValueInterceptor.java:204)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:99)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:64)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:77)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:274)
>         at org.infinispan.CacheImpl.keySet(CacheImpl.java:261)
>         at org.infinispan.AbstractDelegatingCache.keySet(AbstractDelegatingCache.java:261)
>         at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getSessionIds(DistributedCacheManager.java:413)
>         at org.jboss.as.web.session.DistributableSessionManager.initializeUnloadedSessions(DistributableSessionManager.java:299) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.as.web.session.DistributableSessionManager.start(DistributableSessionManager.java:201) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.apache.catalina.core.StandardContext.start(StandardContext.java:3830) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
>         at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
>         at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: java.lang.ClassNotFoundException: org.jboss.as.clustering.web.infinispan.DistributedCacheManagerFactory$SessionKeyImpl from [Module "deployment.make-love-not.war:main" from Service Module Loader]
>         at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
>         at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
>         at java.lang.Class.forName0(Native Method) [:1.6.0_26]
>         at java.lang.Class.forName(Class.java:247) [:1.6.0_26]
>         at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
>         at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:888)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1200)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
>         at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
>         at org.infinispan.marshall.jboss.GenericJBossMarshaller.objectFromObjectStream(GenericJBossMarshaller.java:191)
>         at org.infinispan.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:122)
>         at org.infinispan.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:98)
>         at org.infinispan.marshall.MarshalledValue.deserialize0(MarshalledValue.java:143)
>         ... 34 more
> 16:48:05,392 ERROR [org.jboss.as.web.session.DistributableSessionManager.make-love-not] (MSC service thread 1-4) Unable to start manager.: org.infinispan.CacheException: Unable to unmarshall value
>         at org.infinispan.marshall.MarshalledValue.deserialize0(MarshalledValue.java:148)
>         at org.infinispan.marshall.MarshalledValue.deserialize(MarshalledValue.java:132)
>         at org.infinispan.marshall.MarshalledValue.get(MarshalledValue.java:213)
>         at org.infinispan.interceptors.MarshalledValueInterceptor.visitKeySetCommand(MarshalledValueInterceptor.java:204)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:99)
>         at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:64)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:133)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:119)
>         at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:77)
>         at org.infinispan.commands.AbstractVisitor.visitKeySetCommand(AbstractVisitor.java:94)
>         at org.infinispan.commands.read.KeySetCommand.acceptVisitor(KeySetCommand.java:55)
>         at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:274)
>         at org.infinispan.CacheImpl.keySet(CacheImpl.java:261)
>         at org.infinispan.AbstractDelegatingCache.keySet(AbstractDelegatingCache.java:261)
>         at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getSessionIds(DistributedCacheManager.java:413)
>         at org.jboss.as.web.session.DistributableSessionManager.initializeUnloadedSessions(DistributableSessionManager.java:299) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.as.web.session.DistributableSessionManager.start(DistributableSessionManager.java:201) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.apache.catalina.core.StandardContext.start(StandardContext.java:3830) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
>         at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
>         at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: java.lang.ClassNotFoundException: org.jboss.as.clustering.web.infinispan.DistributedCacheManagerFactory$SessionKeyImpl from [Module "deployment.make-love-not.war:main" from Service Module Loader]
>         at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
>         at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
>         at java.lang.Class.forName0(Native Method) [:1.6.0_26]
>         at java.lang.Class.forName(Class.java:247) [:1.6.0_26]
>         at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:135)
>         at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:116)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:888)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1200)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
>         at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
>         at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
>         at org.infinispan.marshall.jboss.GenericJBossMarshaller.objectFromObjectStream(GenericJBossMarshaller.java:191)
>         at org.infinispan.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:122)
>         at org.infinispan.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:98)
>         at org.infinispan.marshall.MarshalledValue.deserialize0(MarshalledValue.java:143)
>         ... 34 more
> 16:48:05,398 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-4) Context [/make-love-not] startup failed due to previous errors: LifecycleException:  org.infinispan.CacheException: Unable to unmarshall value
>         at org.jboss.as.web.session.DistributableSessionManager.start(DistributableSessionManager.java:213) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.apache.catalina.core.StandardContext.start(StandardContext.java:3830) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
>         at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
>         at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> 16:48:05,399 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-4) Context [/make-love-not] startup failed due to previous errors
> 16:48:05,400 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-4) Exception during cleanup after start failed: java.lang.NullPointerException
>         at org.jboss.as.web.session.DistributableSessionManager.stop(DistributableSessionManager.java:460)
>         at org.apache.catalina.core.StandardContext.stop(StandardContext.java:3966)
>         at org.apache.catalina.core.StandardContext.start(StandardContext.java:3888)
>         at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70)
>         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_26]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
>         at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> 16:48:05,402 INFO  [org.apache.catalina.core.ContainerBase] (MSC service thread 1-4) Container org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/make-love-not].[jsp] has not been started
> 16:48:05,402 INFO  [org.apache.catalina.core.ContainerBase] (MSC service thread 1-4) Container org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/make-love-not].[default] has not been started
> 16:48:05,420 INFO  [org.jboss.web] (MSC service thread 1-4) registering web context: /make-love-not
> 16:48:05,430 INFO  [org.jboss.as.server.controller] (Controller Boot Thread) Deployed "make-love-not.war"
> 16:48:05,438 INFO  [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.0.Final "Lightning" started in 4906ms - Started 126 of 204 services (78 services are passive or on-demand)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 18:00:23 2011
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Thu, 14 Jul 2011 18:00:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3142) Exception when
 using "from" with mixed collections
Message-ID: <265296785.54623.1310680823745.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Exception when using "from" with mixed collections
--------------------------------------------------

                 Key: JBRULES-3142
                 URL: https://issues.jboss.org/browse/JBRULES-3142
             Project: Drools
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
    Affects Versions: 5.2.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor


when you write "Type() from $source", all elements in the collection $source must be assignable to Type(), otherwise an Exception is thrown

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 20:38:23 2011
From: jira-events at lists.jboss.org (Takayoshi Kimura (JIRA))
Date: Thu, 14 Jul 2011 20:38:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1289) Unnecessary URL
 reconstruction in management console
Message-ID: <946052265.54997.1310690303707.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Unnecessary URL reconstruction in management console 
-----------------------------------------------------

                 Key: AS7-1289
                 URL: https://issues.jboss.org/browse/AS7-1289
             Project: Application Server 7
          Issue Type: Bug
          Components: Console
    Affects Versions: 7.0.0.Final
            Reporter: Takayoshi Kimura
            Assignee: Heiko Braun
            Priority: Minor


Management console redirects "/console" to "/console/index.html"and it reconstructs URL from management interface definition. 

ext.example.com:9990/console -> local.example.com:9990/console/index.html

This URL reconstruction is not necessary and it's better to keep current URL server/port values.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 20:44:23 2011
From: jira-events at lists.jboss.org (Takayoshi Kimura (JIRA))
Date: Thu, 14 Jul 2011 20:44:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1289) Unnecessary URL
 reconstruction in management console
In-Reply-To: <946052265.54997.1310690303707.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <923898537.55007.1310690663634.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Takayoshi Kimura reassigned AS7-1289:
-------------------------------------

    Assignee: Takayoshi Kimura  (was: Heiko Braun)


> Unnecessary URL reconstruction in management console 
> -----------------------------------------------------
>
>                 Key: AS7-1289
>                 URL: https://issues.jboss.org/browse/AS7-1289
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Console
>    Affects Versions: 7.0.0.Final
>            Reporter: Takayoshi Kimura
>            Assignee: Takayoshi Kimura
>            Priority: Minor
>
> Management console redirects "/console" to "/console/index.html"and it reconstructs URL from management interface definition. 
> ext.example.com:9990/console -> local.example.com:9990/console/index.html
> This URL reconstruction is not necessary and it's better to keep current URL server/port values.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 14 23:53:23 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 14 Jul 2011 23:53:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1888) MessageProxy
 contains a field that is not serializable (added since JBMESSAGING-1878)
Message-ID: <933388436.55144.1310702003761.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

MessageProxy contains a field that is not serializable (added since JBMESSAGING-1878)
-------------------------------------------------------------------------------------

                 Key: JBMESSAGING-1888
                 URL: https://issues.jboss.org/browse/JBMESSAGING-1888
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Facade
    Affects Versions: 1.4.8.SP1, 1.4.0.SP3.CP13
            Reporter: Yong Hao Gao
            Assignee: Yong Hao Gao
             Fix For: 1.4.0.SP3.CP14, 1.4.8.SP2


MessageProxy is a serializable class, therefore all its fields (non-transient) need to be serializable too.

The field (source) is an instance of CallbackManager, which is a non-serializable class. Make it transient should solve the problem.



--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 02:24:23 2011
From: jira-events at lists.jboss.org (Jean-Frederic Clere (JIRA))
Date: Fri, 15 Jul 2011 02:24:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1284) Accessing
 localhost:8080 using JBoss Web Native causes
 java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
In-Reply-To: <2087989740.53707.1310651303687.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1506100176.55558.1310711063690.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jean-Frederic Clere commented on AS7-1284:
------------------------------------------

I have:
+++
macosx:~ jfclere$ java -d32 -version
Cannot run Java in 32 bit mode. Continuing in 64 bit mode.
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04-307-9M3263)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03-307, mixed mode)
+++
Where did you get the 32 bits or a mixed version?

> Accessing localhost:8080 using JBoss Web Native causes java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1284
>                 URL: https://issues.jboss.org/browse/AS7-1284
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>         Environment: Darwin osx-en-jwegne.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) Client VM (build 20.1-b02-384, mixed mode)
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)
>            Reporter: Josef Wegner
>            Assignee: Remy Maucherat
>            Priority: Minor
>         Attachments: libtcnative-1.jnilib
>
>
> Hi,
> accessing http://localhost:8080 using JBoss Web Native 2.0.9 (self compiled for x64 and downloaded from http://www.jboss.org/jbossweb/downloads/jboss-native-2-0-9.html for i386) causes following stack trace:
> {quote}
> 15:23:18,710 ERROR [org.apache.coyote.http11.Http11AprProtocol] (http--127.0.0.1-8080-1) Error reading request, ignored: java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> 	at org.apache.tomcat.jni.Socket.setrbb(Native Method)
> 	at org.apache.coyote.http11.InternalAprInputBuffer.setSocket(InternalAprInputBuffer.java:202)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:825)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: java.lang.ClassNotFoundException: sun.nio.ch.DirectBuffer from [Module "org.jboss.as.web:main" from local module loader @39e87719 (roots: /Users/jwegne/Tools/jboss-as-web-7.0.0.Final/modules)]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
> 	... 6 more
> {quote}
> This happens with only when using JDK 1.6 provided by Apple. OpenJDK 1.7 (self-compiled) works, though.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 02:53:23 2011
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 15 Jul 2011 02:53:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1290) add cls/clear command
Message-ID: <449572388.55670.1310712803624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

add cls/clear command
---------------------

                 Key: AS7-1290
                 URL: https://issues.jboss.org/browse/AS7-1290
             Project: Application Server 7
          Issue Type: Task
          Components: CLI
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: 7.0.1.Final


Add a command to clear the terminal.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 03:05:23 2011
From: jira-events at lists.jboss.org (Josef Wegner (JIRA))
Date: Fri, 15 Jul 2011 03:05:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1284) Accessing
 localhost:8080 using JBoss Web Native causes
 java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
In-Reply-To: <2087989740.53707.1310651303687.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1241966403.55693.1310713523659.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Josef Wegner commented on AS7-1284:
-----------------------------------

I got the latest Java Update from Apple via Software update (1.6.0_26) and also installed the latested Java development kit from http://connect.apple.com/ (javadeveloper_for_mac_os_x_10.6__10m3425.dmg).

It seems that one of the both above installed also the 32bit Java version.

> Accessing localhost:8080 using JBoss Web Native causes java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1284
>                 URL: https://issues.jboss.org/browse/AS7-1284
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>         Environment: Darwin osx-en-jwegne.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) Client VM (build 20.1-b02-384, mixed mode)
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)
>            Reporter: Josef Wegner
>            Assignee: Remy Maucherat
>            Priority: Minor
>         Attachments: libtcnative-1.jnilib
>
>
> Hi,
> accessing http://localhost:8080 using JBoss Web Native 2.0.9 (self compiled for x64 and downloaded from http://www.jboss.org/jbossweb/downloads/jboss-native-2-0-9.html for i386) causes following stack trace:
> {quote}
> 15:23:18,710 ERROR [org.apache.coyote.http11.Http11AprProtocol] (http--127.0.0.1-8080-1) Error reading request, ignored: java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> 	at org.apache.tomcat.jni.Socket.setrbb(Native Method)
> 	at org.apache.coyote.http11.InternalAprInputBuffer.setSocket(InternalAprInputBuffer.java:202)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:825)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: java.lang.ClassNotFoundException: sun.nio.ch.DirectBuffer from [Module "org.jboss.as.web:main" from local module loader @39e87719 (roots: /Users/jwegne/Tools/jboss-as-web-7.0.0.Final/modules)]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
> 	... 6 more
> {quote}
> This happens with only when using JDK 1.6 provided by Apple. OpenJDK 1.7 (self-compiled) works, though.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 03:21:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Fri, 15 Jul 2011 03:21:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1291) UserTransaction not
 exposed in JDNI
Message-ID: <1777564578.55712.1310714483625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

UserTransaction not exposed in JDNI
-----------------------------------

                 Key: AS7-1291
                 URL: https://issues.jboss.org/browse/AS7-1291
             Project: Application Server 7
          Issue Type: Bug
          Components: Naming
    Affects Versions: 7.0.0.Final
         Environment: 7.1.0.Alpha1 Jenkins build 1402
            Reporter: Juergen Zimmermann
            Assignee: John Bailey


In JBoss 6 UserTransaction was exposed in JNDI named as java:comp/UserTransaction. Thus an Arquillian test method could be encapsulated in one single transaction:
* lookup() the UserTransaction
* begin() inside @Before
* commit() inside @After
Unfortunately, JBoss 7 doesn't have a JNDI entry for UserTransaction.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 03:26:23 2011
From: jira-events at lists.jboss.org (Wolfgang Knauf (JIRA))
Date: Fri, 15 Jul 2011 03:26:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1292) Cleanup xsd names for
 server config
Message-ID: <1797699218.55716.1310714783611.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Cleanup xsd names for server config
-----------------------------------

                 Key: AS7-1292
                 URL: https://issues.jboss.org/browse/AS7-1292
             Project: Application Server 7
          Issue Type: Bug
          Components: Server
    Affects Versions: 7.0.0.Final
            Reporter: Wolfgang Knauf
            Assignee: Jason Greene
            Priority: Minor
             Fix For: 7.0.1.Final


>From a conversation on the dev mailing list beetween me and Brian: 

>>> [Wolfgang] If my understanding is correct, the naming of the server config xsd
>>> files is confusing, because a "jboss-7_0.xsd" will be something
>>> different than "jboss_6_0.xsd".
>>>
>>
>> [Brian] Yep. Kind of a big DOH!! moment. Looking at the jboss-metadata project
>> where these deployment descriptor dtds/xsds come from, I see no
>> jboss_6_0.xsd, just jboss_6_0.dtd. And no 7_0 xsd or dtd. But still,
>> it's a naming conflict that's bound to bite us unless fixed.
>>
>> I recommend these server config xds all be renamed to
>> jboss-as-XXX_1_0.xsd. They all have an xmlns of
>> urn:jboss:domain:XXX:1.0, not 7.0, which IMO is fine since they may get
>> revved independently of community AS releases.
>>
>
>
> [Wolfgang} Is there something more I should do - e.g. filing a JIRA issue? Or will
> it be fixed by "miracle" ;-) or has someone this already on his todo list ?
>

[Brian] If you could file a JIRA and assign it to me, Fix Version 7.0.1.Final, I'd appreciate it. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 03:30:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 15 Jul 2011 03:30:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1292) Cleanup xsd names
 for server config
In-Reply-To: <1797699218.55716.1310714783611.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <643116918.55727.1310715023673.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai reassigned AS7-1292:
---------------------------------

    Assignee: Brian Stansberry  (was: Jason Greene)


> Cleanup xsd names for server config
> -----------------------------------
>
>                 Key: AS7-1292
>                 URL: https://issues.jboss.org/browse/AS7-1292
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 7.0.0.Final
>            Reporter: Wolfgang Knauf
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: 7.0.1.Final
>
>
> From a conversation on the dev mailing list beetween me and Brian: 
> >>> [Wolfgang] If my understanding is correct, the naming of the server config xsd
> >>> files is confusing, because a "jboss-7_0.xsd" will be something
> >>> different than "jboss_6_0.xsd".
> >>>
> >>
> >> [Brian] Yep. Kind of a big DOH!! moment. Looking at the jboss-metadata project
> >> where these deployment descriptor dtds/xsds come from, I see no
> >> jboss_6_0.xsd, just jboss_6_0.dtd. And no 7_0 xsd or dtd. But still,
> >> it's a naming conflict that's bound to bite us unless fixed.
> >>
> >> I recommend these server config xds all be renamed to
> >> jboss-as-XXX_1_0.xsd. They all have an xmlns of
> >> urn:jboss:domain:XXX:1.0, not 7.0, which IMO is fine since they may get
> >> revved independently of community AS releases.
> >>
> >
> >
> > [Wolfgang} Is there something more I should do - e.g. filing a JIRA issue? Or will
> > it be fixed by "miracle" ;-) or has someone this already on his todo list ?
> >
> [Brian] If you could file a JIRA and assign it to me, Fix Version 7.0.1.Final, I'd appreciate it. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 03:35:25 2011
From: jira-events at lists.jboss.org (Quanlin Chen (JIRA))
Date: Fri, 15 Jul 2011 03:35:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1293) JNDI Binding service
Message-ID: <91757685.55770.1310715325126.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

JNDI Binding service
--------------------

                 Key: AS7-1293
                 URL: https://issues.jboss.org/browse/AS7-1293
             Project: Application Server 7
          Issue Type: Feature Request
    Affects Versions: 7.0.0.Final
            Reporter: Quanlin Chen
            Priority: Critical


I was just been told that so far it's impossible to bind arbitrary objects into JNDI in JBOSS 7, so would you be able to create a common binding service so that it could be working the same way as using JMX in previous AS versions?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 03:41:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 15 Jul 2011 03:41:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1294) Don't inject into
 static fields/methods
Message-ID: <204098316.55797.1310715683666.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Don't inject into static fields/methods
---------------------------------------

                 Key: AS7-1294
                 URL: https://issues.jboss.org/browse/AS7-1294
             Project: Application Server 7
          Issue Type: Bug
          Components: EE
    Affects Versions: 7.0.0.Final
            Reporter: jaikiran pai
            Assignee: David Lloyd


The Java EE6 spec, section EE.5.2.5 says:

{quote}
The field or method may have any access qualifier (public, private, etc.). For all classes except application client
main classes, the fields or methods must not be static.
{quote}

Currently we even inject even into static fields/methods.

 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 03:41:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 15 Jul 2011 03:41:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1294) Don't inject into
 static fields/methods
In-Reply-To: <204098316.55797.1310715683666.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1154405232.55802.1310715683786.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai reassigned AS7-1294:
---------------------------------

    Assignee: jaikiran pai  (was: David Lloyd)


> Don't inject into static fields/methods
> ---------------------------------------
>
>                 Key: AS7-1294
>                 URL: https://issues.jboss.org/browse/AS7-1294
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 7.0.0.Final
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> The Java EE6 spec, section EE.5.2.5 says:
> {quote}
> The field or method may have any access qualifier (public, private, etc.). For all classes except application client
> main classes, the fields or methods must not be static.
> {quote}
> Currently we even inject even into static fields/methods.
>  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 03:41:23 2011
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Fri, 15 Jul 2011 03:41:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1294) Don't inject into
 static fields/methods
In-Reply-To: <204098316.55797.1310715683666.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <942871706.55804.1310715683830.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

SBS JIRA Integration updated AS7-1294:
--------------------------------------

    Forum Reference: http://community.jboss.org/message/615371#615371


> Don't inject into static fields/methods
> ---------------------------------------
>
>                 Key: AS7-1294
>                 URL: https://issues.jboss.org/browse/AS7-1294
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 7.0.0.Final
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> The Java EE6 spec, section EE.5.2.5 says:
> {quote}
> The field or method may have any access qualifier (public, private, etc.). For all classes except application client
> main classes, the fields or methods must not be static.
> {quote}
> Currently we even inject even into static fields/methods.
>  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 04:25:23 2011
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 15 Jul 2011 04:25:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1238) only commands for
 the available subsystems should be available
In-Reply-To: <722543698.43236.1310197763622.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1802097127.55865.1310718323666.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Alexey Loubyansky resolved AS7-1238.
------------------------------------

    Resolution: Done


Fixed.

> only commands for the available subsystems should be available
> --------------------------------------------------------------
>
>                 Key: AS7-1238
>                 URL: https://issues.jboss.org/browse/AS7-1238
>             Project: Application Server 7
>          Issue Type: Task
>          Components: CLI
>    Affects Versions: 7.0.0.CR1
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 7.0.1.Final
>
>
> (1) I start the standalone mode with the standard standalone.xml (i.e 
> web profile no messaging etc.)
> (2) I connect to server using jboss-admin.
> (3) I type help on jboss-admin console and get to see commands like 
> add-jms-topic etc.
> (4) try executing add-jms-queue command and get the error : "No handler ..." since the jms subsystem isn't available in the current configuration.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 04:27:23 2011
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 15 Jul 2011 04:27:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1259) remove
 add/modify/remove-[xa-]data-source commands
In-Reply-To: <884327167.48012.1310473703617.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1294904254.55869.1310718443640.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Alexey Loubyansky resolved AS7-1259.
------------------------------------

    Fix Version/s: 7.0.1.Final
       Resolution: Done


The commands are still supported but removed from the tab-completion.

> remove add/modify/remove-[xa-]data-source commands
> --------------------------------------------------
>
>                 Key: AS7-1259
>                 URL: https://issues.jboss.org/browse/AS7-1259
>             Project: Application Server 7
>          Issue Type: Task
>          Components: CLI
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 7.0.1.Final
>
>
> These commands should be removed in favour of the generic type commands data-source and xa-data-source.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 05:17:23 2011
From: jira-events at lists.jboss.org (Trustin Lee (JIRA))
Date: Fri, 15 Jul 2011 05:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-1272) Infinispan subsystem
 configures its transport with invalid timeout values.
In-Reply-To: <1505967125.49711.1310531183918.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <478878219.55937.1310721443676.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Trustin Lee closed AS7-1272.
----------------------------

    Resolution: Rejected


Invalid report.  Not AS7 bug but ISPN bug - ISPN-1231

> Infinispan subsystem configures its transport with invalid timeout values.
> --------------------------------------------------------------------------
>
>                 Key: AS7-1272
>                 URL: https://issues.jboss.org/browse/AS7-1272
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.Final
>            Reporter: Trustin Lee
>            Assignee: Paul Ferraro
>
> Whenever I start the Infinispan subsystem, I see the following warning:
> {code}
> 13:20:23,854 WARN  [org.infinispan.config.TimeoutConfigurationValidatingVisitor] (MSC service thread 1-4) ISPN00148: Invalid <transport>: distributedSyncTimout value of 240000. It can not be higher than <stateRetrieval>:timeout which is 10000
> {code}
> The current subsystem configuration looks like the following:
> {code}
>         <subsystem xmlns="urn:jboss:domain:infinispan:1.0" default-cache-container="default">
>             <cache-container name="default"
>                              default-cache="default"
>                              listener-executor="infinispan-listener"
>                              eviction-executor="infinispan-eviction"
>                              replication-queue-executor="infinispan-repl-queue">
>                 <transport executor="infinispan-transport"
>                            lock-timeout="240000"/>
>                 <distributed-cache name="default"
>                                    start="EAGER"
>                                    mode="SYNC"
>                                    virtual-nodes="1" 
>                                    owners="2" 
>                                    batching="false" 
>                                    indexing="NONE" 
>                                    l1-lifespan="0" 
>                                    remote-timeout="30000">
>                     <locking isolation="REPEATABLE_READ" 
>                              acquire-timeout="30000" 
>                              concurrency-level="1000" 
>                              striping="false" />
>                     <rehashing enabled="true" 
>                                timeout="600000" />
>                 </distributed-cache>
>             </cache-container>
>         </subsystem>
> {code}
> It seems like there are not all attribute that correspond to all transport timeout properties.  If that's intended, as least the subsystem should feed the sensible defaults to Infinispan.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 05:42:23 2011
From: jira-events at lists.jboss.org (Sanne Grinovero (JIRA))
Date: Fri, 15 Jul 2011 05:42:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1345) JDBC_PING fails to
 initialize table in mysql
In-Reply-To: <146558224.51504.1310586863624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <563918358.55945.1310722943696.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Sanne Grinovero commented on JGRP-1345:
---------------------------------------

yes that's the code to initialize the table. But it's not the code writing to it ;)
The error should be logger in
{code}org.jgroups.protocols.JDBC_PING.writeToFile(PingData, String){code}

There's no point in failing if we couldn't initialize the table, as most databases don't support the _IF NOT EXISTS_ clause, so everyone but the first fill fail. In fact in most environments the applications are not allowed at all to change the schema, so the DBA should create the table and define the SQL fragments he wants JGroups to use.. so _attemptSchemaInitialization_ is really just a temptative to make your life easier, but an error is not critical at all.

> JDBC_PING fails to initialize table in mysql
> --------------------------------------------
>
>                 Key: JGRP-1345
>                 URL: https://issues.jboss.org/browse/JGRP-1345
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.12
>            Reporter: Ra?l Raja Mart?nez
>            Assignee: Sanne Grinovero
>             Fix For: 2.12.2, 3.0
>
>
> JDBC_PING fails to initialize DB table for discover when executing the following SQL:
> CREATE TABLE JGROUPSPING (own_addr varchar(200) NOT NULL, cluster_name varchar(200) NOT NULL, ping_data varbinary(5000) DEFAULT NULL, PRIMARY KEY (own_addr, cluster_name) )
> The statement results in "Specified key was too long; max key length is 1000 bytes"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Fri Jul 15 05:46:23 2011
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Fri, 15 Jul 2011 05:46:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3143) Knowledge Agent
 does not handle multiple packages in Builder output from single resource
Message-ID: <1469969996.55952.1310723183785.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Knowledge Agent does not handle multiple packages in Builder output from single resource
----------------------------------------------------------------------------------------

                 Key: JBRULES-3143
                 URL: https://issues.jboss.org/browse/JBRULES-3143
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core  (expert)
    Affects Versions: 5.2.0.Final
            Reporter: Wolfgang Laun
            Assignee: Mark Proctor
            Priority: Blocker
             Fix For: 5.2.1.Final


Note: see also https://issues.jboss.org/browse/JBRULES-2940

KnowledgeAgent with a ChecngeSet containing a single DRL:
   package x
   import y.Type
   declare Type
      @role(event)
   end
   //...rules etc.

If this is passed to the builder, it'll return two KnowledgePackageImpl objects, one with name 'x' and another one with name 'y'. But the KA only takes the first package from the Collection of packages returned by the builder.

=!=> KA must process all packages from the builder.

=!=> Incremental kBase building requires diff-ing between old/new packages. This, then, must take into account that contribution to one package can come from several resource builds.

=!=> The idea that the kBuilder should return packages with different names from a single DRL build is probably wrong. If a Drools package foo contains an import bar.Type, then this is still an asset in package foo and needs to be handled as a type reference in foo. Any annotation additions must be carried by that asset foo. (The *Java* package of the imported bar.Type remains of course bar.)


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 06:15:24 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Fri, 15 Jul 2011 06:15:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMESSAGING-1888) MessageProxy
 contains a field that is not serializable (added since JBMESSAGING-1878)
In-Reply-To: <933388436.55144.1310702003761.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1238339703.55997.1310724924350.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao resolved JBMESSAGING-1888.
---------------------------------------

    Resolution: Done


> MessageProxy contains a field that is not serializable (added since JBMESSAGING-1878)
> -------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1888
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1888
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.4.0.SP3.CP13, 1.4.8.SP1
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP14, 1.4.8.SP2
>
>
> MessageProxy is a serializable class, therefore all its fields (non-transient) need to be serializable too.
> The field (source) is an instance of CallbackManager, which is a non-serializable class. Make it transient should solve the problem.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 06:15:24 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Fri, 15 Jul 2011 06:15:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1888) MessageProxy
 contains a field that is not serializable (added since JBMESSAGING-1878)
In-Reply-To: <933388436.55144.1310702003761.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2091617694.56003.1310724924470.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao closed JBMESSAGING-1888.
-------------------------------------



> MessageProxy contains a field that is not serializable (added since JBMESSAGING-1878)
> -------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1888
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1888
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.4.0.SP3.CP13, 1.4.8.SP1
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP14, 1.4.8.SP2
>
>
> MessageProxy is a serializable class, therefore all its fields (non-transient) need to be serializable too.
> The field (source) is an instance of CallbackManager, which is a non-serializable class. Make it transient should solve the problem.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 06:20:23 2011
From: jira-events at lists.jboss.org (Oved O (JIRA))
Date: Fri, 15 Jul 2011 06:20:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1295) interceptors are
 ignored when they are in <ear>/lib
Message-ID: <1598263671.56012.1310725223676.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

interceptors are ignored when they are in <ear>/lib
---------------------------------------------------

                 Key: AS7-1295
                 URL: https://issues.jboss.org/browse/AS7-1295
             Project: Application Server 7
          Issue Type: Bug
          Components: Naming
    Affects Versions: 7.0.0.Final
         Environment: fedora 14
            Reporter: Oved O
            Assignee: John Bailey
         Attachments: reproduction.tar.gz

When an ejb have interceptor classes from jars in <ear>/lib, those interceptors are ignored.

For example (this example is attached), assuming you have a jar in the lib directory, with MyInterceptor class, and a deployed jar with two ejbs (MyRegularUser and CallingRegularUser) and a local interceptor (MyLocalInterceptor).

The CallingRegularUser depends on MyRegularUser ejb, and on the post process method it calls a method of MyRegularUser.
When called, both MyLocalInterceptor and MyInterceptor should run, but only MyLocalInterceptor runs.

The log:
[oourfali at dhcp-1-30 bin]$  ./standalone.sh --server-config=standalone-preview.xml
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /home/tlv/oourfali/jboss-7.0.0.CR1

  JAVA: /usr/java/jdk1.6.0_24/bin/java

  JAVA_OPTS: -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 -Xrunjdwp:transport=dt_socket,address=7766,server=y,suspend=n

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

Listening for transport dt_socket at address: 7766
12:46:21,780 INFO  [org.jboss.modules] JBoss Modules version 1.0.0.CR4
12:46:22,027 INFO  [org.jboss.msc] JBoss MSC version 1.0.0.CR2
12:46:22,083 INFO  [org.jboss.as] JBoss AS 7.0.0.CR1 "White Rabbit" starting
12:46:23,065 INFO  [org.jboss.as] creating http management service using network interface (management) port (9990) securePort (-1)
12:46:23,077 INFO  [org.jboss.as.logging] Removing bootstrap log handlers
12:46:23,095 INFO  [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying JDBC-compliant driver class org.h2.Driver (version 1.2)
12:46:23,101 INFO  [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 9.0)
12:46:23,187 INFO  [org.jboss.as.jacorb] (Controller Boot Thread) Activating JacORB Subsystem
12:46:23,319 INFO  [org.jboss.as.naming] (Controller Boot Thread) Activating Naming Subsystem
12:46:23,333 INFO  [org.jboss.as.naming] (MSC service thread 1-1) Starting Naming Service 
12:46:23,344 INFO  [org.jboss.as.osgi] (Controller Boot Thread) Activating OSGi Subsystem
12:46:23,364 INFO  [org.jboss.as.security] (Controller Boot Thread) Activating Security Subsystem
12:46:23,372 INFO  [org.jboss.remoting] (MSC service thread 1-5) JBoss Remoting version 3.2.0.Beta2
12:46:23,388 INFO  [org.xnio] (MSC service thread 1-5) XNIO Version 3.0.0.Beta3
12:46:23,405 INFO  [org.xnio.nio] (MSC service thread 1-5) XNIO NIO Implementation Version 3.0.0.Beta3
12:46:23,522 INFO  [org.jboss.as.webservices] (Controller Boot Thread) Activating WebServices Extension
12:46:23,527 INFO  [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-8) The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/java/jdk1.6.0_24/jre/lib/amd64/server:/usr/java/jdk1.6.0_24/jre/lib/amd64:/usr/java/jdk1.6.0_24/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
12:46:23,605 INFO  [org.jboss.as.remoting] (MSC service thread 1-8) Listening on /10.35.203.35:9999
12:46:23,607 INFO  [org.jboss.as.jmx.JMXConnectorService] (MSC service thread 1-6) Starting remote JMX connector
12:46:23,628 INFO  [org.jboss.as.ee] (Controller Boot Thread) Activating EE subsystem
12:46:23,659 WARN  [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-5) Unable to set the URLStreamHandlerFactory
12:46:23,667 WARN  [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-5) Unable to set the ContentHandlerFactory
12:46:23,821 INFO  [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-7) JBoss Web Services - Stack CXF Server 4.0.0.Beta2
12:46:23,829 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-3) Starting Coyote HTTP/1.1 on http-vpn-203-35.tlv.redhat.com-10.35.203.35-8080
12:46:23,856 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-7) live server is starting with configuration HornetQ Configuration (clustered=false,backup=false,sharedStore=true,journalDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messagingjournal,bindingsDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messagingbindings,largeMessagesDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messaginglargemessages,pagingDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messagingpaging)
12:46:24,001 INFO  [org.jboss.as.connector] (MSC service thread 1-3) Starting JCA Subsystem (JBoss IronJacamar 1.0.0.CR2)
12:46:24,099 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) Bound data source [java:jboss/datasources/ExampleDS]
12:46:24,140 INFO  [org.jboss.as.jacorb] (MSC service thread 1-4) CORBA ORB Service Started
12:46:24,143 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) Bound data source [java:/RHEVMDataSource]
12:46:24,176 INFO  [org.jboss.as.connector.services.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-8) Registered connection factory java:/JmsXA on mdr
12:46:24,197 INFO  [org.hornetq.ra.HornetQResourceAdapter] (MSC service thread 1-8) HornetQ resource adaptor started
12:46:24,197 INFO  [org.jboss.as.connector.services.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-8) IJ020002: Deployed: file://RaActivatorhornetq-ra
12:46:24,350 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-7) Started Netty Acceptor version 3.2.3.Final-r${buildNumber} vpn-203-35.tlv.redhat.com:5455 for CORE protocol
12:46:24,365 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-7) Started Netty Acceptor version 3.2.3.Final-r${buildNumber} vpn-203-35.tlv.redhat.com:5445 for CORE protocol
12:46:24,381 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-7) Server is now live
12:46:24,381 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-7) HornetQ Server version 2.2.6.Final (HQ_2_2_6_FINAL_AS7, 121) [81345b0c-a929-11e0-850e-001a4aebfff4] started
12:46:24,384 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-2) trying to deploy queue jms.queue.testQueue
12:46:24,402 INFO  [org.jboss.as.jacorb] (MSC service thread 1-1) CORBA Naming Service Started
12:46:24,543 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-6) trying to deploy queue jms.topic.testTopic
12:46:24,806 INFO  [org.jboss.as.deployment] (MSC service thread 1-2) Started FileSystemDeploymentService for directory /home/tlv/oourfali/jboss-7.0.0.CR1/standalone/deployments
12:46:24,812 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found reproduction.ear in deployment directory. To trigger deployment create a file called reproduction.ear.dodeploy
12:46:24,812 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found rhevm-genericapi.war in deployment directory. To trigger deployment create a file called rhevm-genericapi.war.dodeploy
12:46:24,812 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found rhevm-genericapi.jar in deployment directory. To trigger deployment create a file called rhevm-genericapi.jar.dodeploy
12:46:24,813 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found rhevm.ear in deployment directory. To trigger deployment create a file called rhevm.ear.dodeploy
12:46:24,824 INFO  [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.0.CR1 "White Rabbit" started in 3253ms - Started 125 of 184 services (59 services are passive or on-demand)
12:46:24,842 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) Starting deployment of "reproduction.ear"
12:46:24,885 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) Starting deployment of "test_reg.jar"
12:46:24,973 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-8) JNDI bindings for session bean named CallingRegularUser in deployment unit subdeployment "test_reg.jar" of deployment "reproduction.ear" are as follows:

        java:global/reproduction/test_reg/CallingRegularUser!reproduction.regular_user.CallingRegularUser
        java:app/test_reg/CallingRegularUser!reproduction.regular_user.CallingRegularUser
        java:module/CallingRegularUser!reproduction.regular_user.CallingRegularUser
        java:global/reproduction/test_reg/CallingRegularUser
        java:app/test_reg/CallingRegularUser
        java:module/CallingRegularUser

12:46:24,973 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-8) JNDI bindings for session bean named MyRegularUser in deployment unit subdeployment "test_reg.jar" of deployment "reproduction.ear" are as follows:

        java:global/reproduction/test_reg/MyRegularUser!reproduction.regular_user.MyRegularUser
        java:app/test_reg/MyRegularUser!reproduction.regular_user.MyRegularUser
        java:module/MyRegularUser!reproduction.regular_user.MyRegularUser
        java:global/reproduction/test_reg/MyRegularUser
        java:app/test_reg/MyRegularUser
        java:module/MyRegularUser

12:46:25,069 INFO  [org.jboss.as.ejb3.deployment.processors.EjbDependsOnAnnotationProcessor] (MSC service thread 1-1) CallingRegularUser bean has @DependsOn
12:46:25,120 INFO  [stdout] (MSC service thread 1-6) My Regular User - initialized
12:46:25,122 INFO  [stdout] (MSC service thread 1-2) CallingRegularUser - calling initialized
12:46:25,129 WARN  [org.jboss.as.ejb3.component.EJBComponent] (MSC service thread 1-2) EJBTHREE-2120: deprecated getTransactionAttributeType method called (dev problem)
12:46:25,132 INFO  [stdout] (MSC service thread 1-2) local interceptor - testing
12:46:25,132 INFO  [stdout] (MSC service thread 1-2) MyRegularUser - doSomething
12:46:25,214 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 2) Deployed "reproduction.ear"


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 06:20:23 2011
From: jira-events at lists.jboss.org (Oved O (JIRA))
Date: Fri, 15 Jul 2011 06:20:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1295) interceptors are
 ignored when they are in <ear>/lib
In-Reply-To: <1598263671.56012.1310725223676.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1874025233.56016.1310725223868.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Oved O updated AS7-1295:
------------------------

    Attachment: reproduction.tar.gz


This is the reproduction ear.

> interceptors are ignored when they are in <ear>/lib
> ---------------------------------------------------
>
>                 Key: AS7-1295
>                 URL: https://issues.jboss.org/browse/AS7-1295
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Naming
>    Affects Versions: 7.0.0.Final
>         Environment: fedora 14
>            Reporter: Oved O
>            Assignee: John Bailey
>         Attachments: reproduction.tar.gz
>
>
> When an ejb have interceptor classes from jars in <ear>/lib, those interceptors are ignored.
> For example (this example is attached), assuming you have a jar in the lib directory, with MyInterceptor class, and a deployed jar with two ejbs (MyRegularUser and CallingRegularUser) and a local interceptor (MyLocalInterceptor).
> The CallingRegularUser depends on MyRegularUser ejb, and on the post process method it calls a method of MyRegularUser.
> When called, both MyLocalInterceptor and MyInterceptor should run, but only MyLocalInterceptor runs.
> The log:
> [oourfali at dhcp-1-30 bin]$  ./standalone.sh --server-config=standalone-preview.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/tlv/oourfali/jboss-7.0.0.CR1
>   JAVA: /usr/java/jdk1.6.0_24/bin/java
>   JAVA_OPTS: -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 -Xrunjdwp:transport=dt_socket,address=7766,server=y,suspend=n
> =========================================================================
> Listening for transport dt_socket at address: 7766
> 12:46:21,780 INFO  [org.jboss.modules] JBoss Modules version 1.0.0.CR4
> 12:46:22,027 INFO  [org.jboss.msc] JBoss MSC version 1.0.0.CR2
> 12:46:22,083 INFO  [org.jboss.as] JBoss AS 7.0.0.CR1 "White Rabbit" starting
> 12:46:23,065 INFO  [org.jboss.as] creating http management service using network interface (management) port (9990) securePort (-1)
> 12:46:23,077 INFO  [org.jboss.as.logging] Removing bootstrap log handlers
> 12:46:23,095 INFO  [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying JDBC-compliant driver class org.h2.Driver (version 1.2)
> 12:46:23,101 INFO  [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 9.0)
> 12:46:23,187 INFO  [org.jboss.as.jacorb] (Controller Boot Thread) Activating JacORB Subsystem
> 12:46:23,319 INFO  [org.jboss.as.naming] (Controller Boot Thread) Activating Naming Subsystem
> 12:46:23,333 INFO  [org.jboss.as.naming] (MSC service thread 1-1) Starting Naming Service 
> 12:46:23,344 INFO  [org.jboss.as.osgi] (Controller Boot Thread) Activating OSGi Subsystem
> 12:46:23,364 INFO  [org.jboss.as.security] (Controller Boot Thread) Activating Security Subsystem
> 12:46:23,372 INFO  [org.jboss.remoting] (MSC service thread 1-5) JBoss Remoting version 3.2.0.Beta2
> 12:46:23,388 INFO  [org.xnio] (MSC service thread 1-5) XNIO Version 3.0.0.Beta3
> 12:46:23,405 INFO  [org.xnio.nio] (MSC service thread 1-5) XNIO NIO Implementation Version 3.0.0.Beta3
> 12:46:23,522 INFO  [org.jboss.as.webservices] (Controller Boot Thread) Activating WebServices Extension
> 12:46:23,527 INFO  [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-8) The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/java/jdk1.6.0_24/jre/lib/amd64/server:/usr/java/jdk1.6.0_24/jre/lib/amd64:/usr/java/jdk1.6.0_24/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
> 12:46:23,605 INFO  [org.jboss.as.remoting] (MSC service thread 1-8) Listening on /10.35.203.35:9999
> 12:46:23,607 INFO  [org.jboss.as.jmx.JMXConnectorService] (MSC service thread 1-6) Starting remote JMX connector
> 12:46:23,628 INFO  [org.jboss.as.ee] (Controller Boot Thread) Activating EE subsystem
> 12:46:23,659 WARN  [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-5) Unable to set the URLStreamHandlerFactory
> 12:46:23,667 WARN  [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-5) Unable to set the ContentHandlerFactory
> 12:46:23,821 INFO  [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-7) JBoss Web Services - Stack CXF Server 4.0.0.Beta2
> 12:46:23,829 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-3) Starting Coyote HTTP/1.1 on http-vpn-203-35.tlv.redhat.com-10.35.203.35-8080
> 12:46:23,856 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-7) live server is starting with configuration HornetQ Configuration (clustered=false,backup=false,sharedStore=true,journalDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messagingjournal,bindingsDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messagingbindings,largeMessagesDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messaginglargemessages,pagingDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messagingpaging)
> 12:46:24,001 INFO  [org.jboss.as.connector] (MSC service thread 1-3) Starting JCA Subsystem (JBoss IronJacamar 1.0.0.CR2)
> 12:46:24,099 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) Bound data source [java:jboss/datasources/ExampleDS]
> 12:46:24,140 INFO  [org.jboss.as.jacorb] (MSC service thread 1-4) CORBA ORB Service Started
> 12:46:24,143 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) Bound data source [java:/RHEVMDataSource]
> 12:46:24,176 INFO  [org.jboss.as.connector.services.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-8) Registered connection factory java:/JmsXA on mdr
> 12:46:24,197 INFO  [org.hornetq.ra.HornetQResourceAdapter] (MSC service thread 1-8) HornetQ resource adaptor started
> 12:46:24,197 INFO  [org.jboss.as.connector.services.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-8) IJ020002: Deployed: file://RaActivatorhornetq-ra
> 12:46:24,350 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-7) Started Netty Acceptor version 3.2.3.Final-r${buildNumber} vpn-203-35.tlv.redhat.com:5455 for CORE protocol
> 12:46:24,365 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-7) Started Netty Acceptor version 3.2.3.Final-r${buildNumber} vpn-203-35.tlv.redhat.com:5445 for CORE protocol
> 12:46:24,381 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-7) Server is now live
> 12:46:24,381 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-7) HornetQ Server version 2.2.6.Final (HQ_2_2_6_FINAL_AS7, 121) [81345b0c-a929-11e0-850e-001a4aebfff4] started
> 12:46:24,384 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-2) trying to deploy queue jms.queue.testQueue
> 12:46:24,402 INFO  [org.jboss.as.jacorb] (MSC service thread 1-1) CORBA Naming Service Started
> 12:46:24,543 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-6) trying to deploy queue jms.topic.testTopic
> 12:46:24,806 INFO  [org.jboss.as.deployment] (MSC service thread 1-2) Started FileSystemDeploymentService for directory /home/tlv/oourfali/jboss-7.0.0.CR1/standalone/deployments
> 12:46:24,812 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found reproduction.ear in deployment directory. To trigger deployment create a file called reproduction.ear.dodeploy
> 12:46:24,812 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found rhevm-genericapi.war in deployment directory. To trigger deployment create a file called rhevm-genericapi.war.dodeploy
> 12:46:24,812 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found rhevm-genericapi.jar in deployment directory. To trigger deployment create a file called rhevm-genericapi.jar.dodeploy
> 12:46:24,813 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found rhevm.ear in deployment directory. To trigger deployment create a file called rhevm.ear.dodeploy
> 12:46:24,824 INFO  [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.0.CR1 "White Rabbit" started in 3253ms - Started 125 of 184 services (59 services are passive or on-demand)
> 12:46:24,842 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) Starting deployment of "reproduction.ear"
> 12:46:24,885 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) Starting deployment of "test_reg.jar"
> 12:46:24,973 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-8) JNDI bindings for session bean named CallingRegularUser in deployment unit subdeployment "test_reg.jar" of deployment "reproduction.ear" are as follows:
>         java:global/reproduction/test_reg/CallingRegularUser!reproduction.regular_user.CallingRegularUser
>         java:app/test_reg/CallingRegularUser!reproduction.regular_user.CallingRegularUser
>         java:module/CallingRegularUser!reproduction.regular_user.CallingRegularUser
>         java:global/reproduction/test_reg/CallingRegularUser
>         java:app/test_reg/CallingRegularUser
>         java:module/CallingRegularUser
> 12:46:24,973 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-8) JNDI bindings for session bean named MyRegularUser in deployment unit subdeployment "test_reg.jar" of deployment "reproduction.ear" are as follows:
>         java:global/reproduction/test_reg/MyRegularUser!reproduction.regular_user.MyRegularUser
>         java:app/test_reg/MyRegularUser!reproduction.regular_user.MyRegularUser
>         java:module/MyRegularUser!reproduction.regular_user.MyRegularUser
>         java:global/reproduction/test_reg/MyRegularUser
>         java:app/test_reg/MyRegularUser
>         java:module/MyRegularUser
> 12:46:25,069 INFO  [org.jboss.as.ejb3.deployment.processors.EjbDependsOnAnnotationProcessor] (MSC service thread 1-1) CallingRegularUser bean has @DependsOn
> 12:46:25,120 INFO  [stdout] (MSC service thread 1-6) My Regular User - initialized
> 12:46:25,122 INFO  [stdout] (MSC service thread 1-2) CallingRegularUser - calling initialized
> 12:46:25,129 WARN  [org.jboss.as.ejb3.component.EJBComponent] (MSC service thread 1-2) EJBTHREE-2120: deprecated getTransactionAttributeType method called (dev problem)
> 12:46:25,132 INFO  [stdout] (MSC service thread 1-2) local interceptor - testing
> 12:46:25,132 INFO  [stdout] (MSC service thread 1-2) MyRegularUser - doSomething
> 12:46:25,214 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 2) Deployed "reproduction.ear"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 06:22:23 2011
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Fri, 15 Jul 2011 06:22:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1295) interceptors are
 ignored when they are in <ear>/lib
In-Reply-To: <1598263671.56012.1310725223676.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <395128162.56021.1310725343820.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

SBS JIRA Integration updated AS7-1295:
--------------------------------------

    Forum Reference: http://community.jboss.org/thread/169472, http://community.jboss.org/message/615371#615371  (was: http://community.jboss.org/thread/169472)


> interceptors are ignored when they are in <ear>/lib
> ---------------------------------------------------
>
>                 Key: AS7-1295
>                 URL: https://issues.jboss.org/browse/AS7-1295
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Naming
>    Affects Versions: 7.0.0.Final
>         Environment: fedora 14
>            Reporter: Oved O
>            Assignee: John Bailey
>         Attachments: reproduction.tar.gz
>
>
> When an ejb have interceptor classes from jars in <ear>/lib, those interceptors are ignored.
> For example (this example is attached), assuming you have a jar in the lib directory, with MyInterceptor class, and a deployed jar with two ejbs (MyRegularUser and CallingRegularUser) and a local interceptor (MyLocalInterceptor).
> The CallingRegularUser depends on MyRegularUser ejb, and on the post process method it calls a method of MyRegularUser.
> When called, both MyLocalInterceptor and MyInterceptor should run, but only MyLocalInterceptor runs.
> The log:
> [oourfali at dhcp-1-30 bin]$  ./standalone.sh --server-config=standalone-preview.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/tlv/oourfali/jboss-7.0.0.CR1
>   JAVA: /usr/java/jdk1.6.0_24/bin/java
>   JAVA_OPTS: -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 -Xrunjdwp:transport=dt_socket,address=7766,server=y,suspend=n
> =========================================================================
> Listening for transport dt_socket at address: 7766
> 12:46:21,780 INFO  [org.jboss.modules] JBoss Modules version 1.0.0.CR4
> 12:46:22,027 INFO  [org.jboss.msc] JBoss MSC version 1.0.0.CR2
> 12:46:22,083 INFO  [org.jboss.as] JBoss AS 7.0.0.CR1 "White Rabbit" starting
> 12:46:23,065 INFO  [org.jboss.as] creating http management service using network interface (management) port (9990) securePort (-1)
> 12:46:23,077 INFO  [org.jboss.as.logging] Removing bootstrap log handlers
> 12:46:23,095 INFO  [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying JDBC-compliant driver class org.h2.Driver (version 1.2)
> 12:46:23,101 INFO  [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 9.0)
> 12:46:23,187 INFO  [org.jboss.as.jacorb] (Controller Boot Thread) Activating JacORB Subsystem
> 12:46:23,319 INFO  [org.jboss.as.naming] (Controller Boot Thread) Activating Naming Subsystem
> 12:46:23,333 INFO  [org.jboss.as.naming] (MSC service thread 1-1) Starting Naming Service 
> 12:46:23,344 INFO  [org.jboss.as.osgi] (Controller Boot Thread) Activating OSGi Subsystem
> 12:46:23,364 INFO  [org.jboss.as.security] (Controller Boot Thread) Activating Security Subsystem
> 12:46:23,372 INFO  [org.jboss.remoting] (MSC service thread 1-5) JBoss Remoting version 3.2.0.Beta2
> 12:46:23,388 INFO  [org.xnio] (MSC service thread 1-5) XNIO Version 3.0.0.Beta3
> 12:46:23,405 INFO  [org.xnio.nio] (MSC service thread 1-5) XNIO NIO Implementation Version 3.0.0.Beta3
> 12:46:23,522 INFO  [org.jboss.as.webservices] (Controller Boot Thread) Activating WebServices Extension
> 12:46:23,527 INFO  [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-8) The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/java/jdk1.6.0_24/jre/lib/amd64/server:/usr/java/jdk1.6.0_24/jre/lib/amd64:/usr/java/jdk1.6.0_24/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
> 12:46:23,605 INFO  [org.jboss.as.remoting] (MSC service thread 1-8) Listening on /10.35.203.35:9999
> 12:46:23,607 INFO  [org.jboss.as.jmx.JMXConnectorService] (MSC service thread 1-6) Starting remote JMX connector
> 12:46:23,628 INFO  [org.jboss.as.ee] (Controller Boot Thread) Activating EE subsystem
> 12:46:23,659 WARN  [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-5) Unable to set the URLStreamHandlerFactory
> 12:46:23,667 WARN  [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-5) Unable to set the ContentHandlerFactory
> 12:46:23,821 INFO  [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-7) JBoss Web Services - Stack CXF Server 4.0.0.Beta2
> 12:46:23,829 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-3) Starting Coyote HTTP/1.1 on http-vpn-203-35.tlv.redhat.com-10.35.203.35-8080
> 12:46:23,856 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-7) live server is starting with configuration HornetQ Configuration (clustered=false,backup=false,sharedStore=true,journalDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messagingjournal,bindingsDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messagingbindings,largeMessagesDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messaginglargemessages,pagingDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messagingpaging)
> 12:46:24,001 INFO  [org.jboss.as.connector] (MSC service thread 1-3) Starting JCA Subsystem (JBoss IronJacamar 1.0.0.CR2)
> 12:46:24,099 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) Bound data source [java:jboss/datasources/ExampleDS]
> 12:46:24,140 INFO  [org.jboss.as.jacorb] (MSC service thread 1-4) CORBA ORB Service Started
> 12:46:24,143 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) Bound data source [java:/RHEVMDataSource]
> 12:46:24,176 INFO  [org.jboss.as.connector.services.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-8) Registered connection factory java:/JmsXA on mdr
> 12:46:24,197 INFO  [org.hornetq.ra.HornetQResourceAdapter] (MSC service thread 1-8) HornetQ resource adaptor started
> 12:46:24,197 INFO  [org.jboss.as.connector.services.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-8) IJ020002: Deployed: file://RaActivatorhornetq-ra
> 12:46:24,350 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-7) Started Netty Acceptor version 3.2.3.Final-r${buildNumber} vpn-203-35.tlv.redhat.com:5455 for CORE protocol
> 12:46:24,365 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-7) Started Netty Acceptor version 3.2.3.Final-r${buildNumber} vpn-203-35.tlv.redhat.com:5445 for CORE protocol
> 12:46:24,381 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-7) Server is now live
> 12:46:24,381 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-7) HornetQ Server version 2.2.6.Final (HQ_2_2_6_FINAL_AS7, 121) [81345b0c-a929-11e0-850e-001a4aebfff4] started
> 12:46:24,384 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-2) trying to deploy queue jms.queue.testQueue
> 12:46:24,402 INFO  [org.jboss.as.jacorb] (MSC service thread 1-1) CORBA Naming Service Started
> 12:46:24,543 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-6) trying to deploy queue jms.topic.testTopic
> 12:46:24,806 INFO  [org.jboss.as.deployment] (MSC service thread 1-2) Started FileSystemDeploymentService for directory /home/tlv/oourfali/jboss-7.0.0.CR1/standalone/deployments
> 12:46:24,812 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found reproduction.ear in deployment directory. To trigger deployment create a file called reproduction.ear.dodeploy
> 12:46:24,812 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found rhevm-genericapi.war in deployment directory. To trigger deployment create a file called rhevm-genericapi.war.dodeploy
> 12:46:24,812 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found rhevm-genericapi.jar in deployment directory. To trigger deployment create a file called rhevm-genericapi.jar.dodeploy
> 12:46:24,813 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found rhevm.ear in deployment directory. To trigger deployment create a file called rhevm.ear.dodeploy
> 12:46:24,824 INFO  [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.0.CR1 "White Rabbit" started in 3253ms - Started 125 of 184 services (59 services are passive or on-demand)
> 12:46:24,842 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) Starting deployment of "reproduction.ear"
> 12:46:24,885 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) Starting deployment of "test_reg.jar"
> 12:46:24,973 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-8) JNDI bindings for session bean named CallingRegularUser in deployment unit subdeployment "test_reg.jar" of deployment "reproduction.ear" are as follows:
>         java:global/reproduction/test_reg/CallingRegularUser!reproduction.regular_user.CallingRegularUser
>         java:app/test_reg/CallingRegularUser!reproduction.regular_user.CallingRegularUser
>         java:module/CallingRegularUser!reproduction.regular_user.CallingRegularUser
>         java:global/reproduction/test_reg/CallingRegularUser
>         java:app/test_reg/CallingRegularUser
>         java:module/CallingRegularUser
> 12:46:24,973 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-8) JNDI bindings for session bean named MyRegularUser in deployment unit subdeployment "test_reg.jar" of deployment "reproduction.ear" are as follows:
>         java:global/reproduction/test_reg/MyRegularUser!reproduction.regular_user.MyRegularUser
>         java:app/test_reg/MyRegularUser!reproduction.regular_user.MyRegularUser
>         java:module/MyRegularUser!reproduction.regular_user.MyRegularUser
>         java:global/reproduction/test_reg/MyRegularUser
>         java:app/test_reg/MyRegularUser
>         java:module/MyRegularUser
> 12:46:25,069 INFO  [org.jboss.as.ejb3.deployment.processors.EjbDependsOnAnnotationProcessor] (MSC service thread 1-1) CallingRegularUser bean has @DependsOn
> 12:46:25,120 INFO  [stdout] (MSC service thread 1-6) My Regular User - initialized
> 12:46:25,122 INFO  [stdout] (MSC service thread 1-2) CallingRegularUser - calling initialized
> 12:46:25,129 WARN  [org.jboss.as.ejb3.component.EJBComponent] (MSC service thread 1-2) EJBTHREE-2120: deprecated getTransactionAttributeType method called (dev problem)
> 12:46:25,132 INFO  [stdout] (MSC service thread 1-2) local interceptor - testing
> 12:46:25,132 INFO  [stdout] (MSC service thread 1-2) MyRegularUser - doSomething
> 12:46:25,214 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 2) Deployed "reproduction.ear"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 07:56:23 2011
From: jira-events at lists.jboss.org (Gary Quinn (JIRA))
Date: Fri, 15 Jul 2011 07:56:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1296) JBREM00200: Remote
 connection failed
Message-ID: <1442430573.56217.1310730983622.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

JBREM00200: Remote connection failed
------------------------------------

                 Key: AS7-1296
                 URL: https://issues.jboss.org/browse/AS7-1296
             Project: Application Server 7
          Issue Type: Bug
    Affects Versions: 7.0.0.Final
            Reporter: Gary Quinn


Downloaded JBoss and followed the "Installing and starting JBoss AS on Linux, Unix or Mac OS X". started the standalone server (jboss-as-7.0.0.Final/bin/standalone.sh)
Server starts but keep logging the following error: 13:57:52,026 ERROR [org.jboss.remoting.remote] (XNIO NIO Read 1) JBREM00200: Remote connection failed: java.io.IOException: Received an invalid message length of 1195725856

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 08:21:23 2011
From: jira-events at lists.jboss.org (Gary Quinn (JIRA))
Date: Fri, 15 Jul 2011 08:21:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-1296) JBREM00200: Remote
 connection failed
In-Reply-To: <1442430573.56217.1310730983622.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1999446242.56252.1310732483640.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Gary Quinn closed AS7-1296.
---------------------------

    Resolution: Rejected


Never mind was my stupidity.

Installed the correct version of maven and it started up fine.

http://maven.apache.org/download.html#Installation

> JBREM00200: Remote connection failed
> ------------------------------------
>
>                 Key: AS7-1296
>                 URL: https://issues.jboss.org/browse/AS7-1296
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Final
>            Reporter: Gary Quinn
>
> Downloaded JBoss and followed the "Installing and starting JBoss AS on Linux, Unix or Mac OS X". started the standalone server (jboss-as-7.0.0.Final/bin/standalone.sh)
> Server starts but keep logging the following error: 13:57:52,026 ERROR [org.jboss.remoting.remote] (XNIO NIO Read 1) JBREM00200: Remote connection failed: java.io.IOException: Received an invalid message length of 1195725856

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 08:35:23 2011
From: jira-events at lists.jboss.org (Shaun Appleton (JIRA))
Date: Fri, 15 Jul 2011 08:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-2261) Allow
 application exceptions to be defined when using the throws clause.
Message-ID: <48907981.56263.1310733323687.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Allow application exceptions to be defined when using the throws clause. 
-------------------------------------------------------------------------

                 Key: EJBTHREE-2261
                 URL: https://issues.jboss.org/browse/EJBTHREE-2261
             Project: EJB 3.0
          Issue Type: Feature Request
            Reporter: Shaun Appleton


Allow application exceptions to be defined when using the throws clause. 

This has been incorporated as part of EJBTHREE-2134 and should be allowed for EJB3 used by EAP 5.x

Depending on the resolution of http://java.net/jira/browse/EJB_SPEC-20 this may be a bug or rfe

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 09:48:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 15 Jul 2011 09:48:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1295) interceptors are
 ignored when they are in <ear>/lib
In-Reply-To: <1598263671.56012.1310725223676.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2104405160.56440.1310737704006.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai updated AS7-1295:
------------------------------

           Assignee: David Lloyd  (was: John Bailey)
        Component/s: EE
                         (was: Naming)
    Forum Reference: http://community.jboss.org/thread/169472, http://community.jboss.org/message/615371#615371  (was: http://community.jboss.org/thread/169472, http://community.jboss.org/message/615371#615371)


> interceptors are ignored when they are in <ear>/lib
> ---------------------------------------------------
>
>                 Key: AS7-1295
>                 URL: https://issues.jboss.org/browse/AS7-1295
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 7.0.0.Final
>         Environment: fedora 14
>            Reporter: Oved O
>            Assignee: David Lloyd
>         Attachments: reproduction.tar.gz
>
>
> When an ejb have interceptor classes from jars in <ear>/lib, those interceptors are ignored.
> For example (this example is attached), assuming you have a jar in the lib directory, with MyInterceptor class, and a deployed jar with two ejbs (MyRegularUser and CallingRegularUser) and a local interceptor (MyLocalInterceptor).
> The CallingRegularUser depends on MyRegularUser ejb, and on the post process method it calls a method of MyRegularUser.
> When called, both MyLocalInterceptor and MyInterceptor should run, but only MyLocalInterceptor runs.
> The log:
> [oourfali at dhcp-1-30 bin]$  ./standalone.sh --server-config=standalone-preview.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/tlv/oourfali/jboss-7.0.0.CR1
>   JAVA: /usr/java/jdk1.6.0_24/bin/java
>   JAVA_OPTS: -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 -Xrunjdwp:transport=dt_socket,address=7766,server=y,suspend=n
> =========================================================================
> Listening for transport dt_socket at address: 7766
> 12:46:21,780 INFO  [org.jboss.modules] JBoss Modules version 1.0.0.CR4
> 12:46:22,027 INFO  [org.jboss.msc] JBoss MSC version 1.0.0.CR2
> 12:46:22,083 INFO  [org.jboss.as] JBoss AS 7.0.0.CR1 "White Rabbit" starting
> 12:46:23,065 INFO  [org.jboss.as] creating http management service using network interface (management) port (9990) securePort (-1)
> 12:46:23,077 INFO  [org.jboss.as.logging] Removing bootstrap log handlers
> 12:46:23,095 INFO  [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying JDBC-compliant driver class org.h2.Driver (version 1.2)
> 12:46:23,101 INFO  [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 9.0)
> 12:46:23,187 INFO  [org.jboss.as.jacorb] (Controller Boot Thread) Activating JacORB Subsystem
> 12:46:23,319 INFO  [org.jboss.as.naming] (Controller Boot Thread) Activating Naming Subsystem
> 12:46:23,333 INFO  [org.jboss.as.naming] (MSC service thread 1-1) Starting Naming Service 
> 12:46:23,344 INFO  [org.jboss.as.osgi] (Controller Boot Thread) Activating OSGi Subsystem
> 12:46:23,364 INFO  [org.jboss.as.security] (Controller Boot Thread) Activating Security Subsystem
> 12:46:23,372 INFO  [org.jboss.remoting] (MSC service thread 1-5) JBoss Remoting version 3.2.0.Beta2
> 12:46:23,388 INFO  [org.xnio] (MSC service thread 1-5) XNIO Version 3.0.0.Beta3
> 12:46:23,405 INFO  [org.xnio.nio] (MSC service thread 1-5) XNIO NIO Implementation Version 3.0.0.Beta3
> 12:46:23,522 INFO  [org.jboss.as.webservices] (Controller Boot Thread) Activating WebServices Extension
> 12:46:23,527 INFO  [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-8) The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/java/jdk1.6.0_24/jre/lib/amd64/server:/usr/java/jdk1.6.0_24/jre/lib/amd64:/usr/java/jdk1.6.0_24/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
> 12:46:23,605 INFO  [org.jboss.as.remoting] (MSC service thread 1-8) Listening on /10.35.203.35:9999
> 12:46:23,607 INFO  [org.jboss.as.jmx.JMXConnectorService] (MSC service thread 1-6) Starting remote JMX connector
> 12:46:23,628 INFO  [org.jboss.as.ee] (Controller Boot Thread) Activating EE subsystem
> 12:46:23,659 WARN  [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-5) Unable to set the URLStreamHandlerFactory
> 12:46:23,667 WARN  [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-5) Unable to set the ContentHandlerFactory
> 12:46:23,821 INFO  [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-7) JBoss Web Services - Stack CXF Server 4.0.0.Beta2
> 12:46:23,829 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-3) Starting Coyote HTTP/1.1 on http-vpn-203-35.tlv.redhat.com-10.35.203.35-8080
> 12:46:23,856 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-7) live server is starting with configuration HornetQ Configuration (clustered=false,backup=false,sharedStore=true,journalDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messagingjournal,bindingsDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messagingbindings,largeMessagesDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messaginglargemessages,pagingDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messagingpaging)
> 12:46:24,001 INFO  [org.jboss.as.connector] (MSC service thread 1-3) Starting JCA Subsystem (JBoss IronJacamar 1.0.0.CR2)
> 12:46:24,099 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) Bound data source [java:jboss/datasources/ExampleDS]
> 12:46:24,140 INFO  [org.jboss.as.jacorb] (MSC service thread 1-4) CORBA ORB Service Started
> 12:46:24,143 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) Bound data source [java:/RHEVMDataSource]
> 12:46:24,176 INFO  [org.jboss.as.connector.services.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-8) Registered connection factory java:/JmsXA on mdr
> 12:46:24,197 INFO  [org.hornetq.ra.HornetQResourceAdapter] (MSC service thread 1-8) HornetQ resource adaptor started
> 12:46:24,197 INFO  [org.jboss.as.connector.services.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-8) IJ020002: Deployed: file://RaActivatorhornetq-ra
> 12:46:24,350 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-7) Started Netty Acceptor version 3.2.3.Final-r${buildNumber} vpn-203-35.tlv.redhat.com:5455 for CORE protocol
> 12:46:24,365 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-7) Started Netty Acceptor version 3.2.3.Final-r${buildNumber} vpn-203-35.tlv.redhat.com:5445 for CORE protocol
> 12:46:24,381 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-7) Server is now live
> 12:46:24,381 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-7) HornetQ Server version 2.2.6.Final (HQ_2_2_6_FINAL_AS7, 121) [81345b0c-a929-11e0-850e-001a4aebfff4] started
> 12:46:24,384 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-2) trying to deploy queue jms.queue.testQueue
> 12:46:24,402 INFO  [org.jboss.as.jacorb] (MSC service thread 1-1) CORBA Naming Service Started
> 12:46:24,543 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-6) trying to deploy queue jms.topic.testTopic
> 12:46:24,806 INFO  [org.jboss.as.deployment] (MSC service thread 1-2) Started FileSystemDeploymentService for directory /home/tlv/oourfali/jboss-7.0.0.CR1/standalone/deployments
> 12:46:24,812 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found reproduction.ear in deployment directory. To trigger deployment create a file called reproduction.ear.dodeploy
> 12:46:24,812 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found rhevm-genericapi.war in deployment directory. To trigger deployment create a file called rhevm-genericapi.war.dodeploy
> 12:46:24,812 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found rhevm-genericapi.jar in deployment directory. To trigger deployment create a file called rhevm-genericapi.jar.dodeploy
> 12:46:24,813 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found rhevm.ear in deployment directory. To trigger deployment create a file called rhevm.ear.dodeploy
> 12:46:24,824 INFO  [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.0.CR1 "White Rabbit" started in 3253ms - Started 125 of 184 services (59 services are passive or on-demand)
> 12:46:24,842 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) Starting deployment of "reproduction.ear"
> 12:46:24,885 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) Starting deployment of "test_reg.jar"
> 12:46:24,973 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-8) JNDI bindings for session bean named CallingRegularUser in deployment unit subdeployment "test_reg.jar" of deployment "reproduction.ear" are as follows:
>         java:global/reproduction/test_reg/CallingRegularUser!reproduction.regular_user.CallingRegularUser
>         java:app/test_reg/CallingRegularUser!reproduction.regular_user.CallingRegularUser
>         java:module/CallingRegularUser!reproduction.regular_user.CallingRegularUser
>         java:global/reproduction/test_reg/CallingRegularUser
>         java:app/test_reg/CallingRegularUser
>         java:module/CallingRegularUser
> 12:46:24,973 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-8) JNDI bindings for session bean named MyRegularUser in deployment unit subdeployment "test_reg.jar" of deployment "reproduction.ear" are as follows:
>         java:global/reproduction/test_reg/MyRegularUser!reproduction.regular_user.MyRegularUser
>         java:app/test_reg/MyRegularUser!reproduction.regular_user.MyRegularUser
>         java:module/MyRegularUser!reproduction.regular_user.MyRegularUser
>         java:global/reproduction/test_reg/MyRegularUser
>         java:app/test_reg/MyRegularUser
>         java:module/MyRegularUser
> 12:46:25,069 INFO  [org.jboss.as.ejb3.deployment.processors.EjbDependsOnAnnotationProcessor] (MSC service thread 1-1) CallingRegularUser bean has @DependsOn
> 12:46:25,120 INFO  [stdout] (MSC service thread 1-6) My Regular User - initialized
> 12:46:25,122 INFO  [stdout] (MSC service thread 1-2) CallingRegularUser - calling initialized
> 12:46:25,129 WARN  [org.jboss.as.ejb3.component.EJBComponent] (MSC service thread 1-2) EJBTHREE-2120: deprecated getTransactionAttributeType method called (dev problem)
> 12:46:25,132 INFO  [stdout] (MSC service thread 1-2) local interceptor - testing
> 12:46:25,132 INFO  [stdout] (MSC service thread 1-2) MyRegularUser - doSomething
> 12:46:25,214 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 2) Deployed "reproduction.ear"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 10:13:33 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 15 Jul 2011 10:13:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1295) interceptors are
 ignored when they are in <ear>/lib
In-Reply-To: <1598263671.56012.1310725223676.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1095753086.56536.1310739213724.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on AS7-1295:
-----------------------------------

{quote}
12:46:24,824 INFO [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.0.CR1 "White Rabbit" started in 3253ms - Started 125 of 184 services (59 services are passive or on-demand)
{quote}

Looks like you are testing this on 7.0 CR1. I tested this against AS7 Final, which has been released, and it works fine there.


> interceptors are ignored when they are in <ear>/lib
> ---------------------------------------------------
>
>                 Key: AS7-1295
>                 URL: https://issues.jboss.org/browse/AS7-1295
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 7.0.0.Final
>         Environment: fedora 14
>            Reporter: Oved O
>            Assignee: David Lloyd
>         Attachments: reproduction.tar.gz
>
>
> When an ejb have interceptor classes from jars in <ear>/lib, those interceptors are ignored.
> For example (this example is attached), assuming you have a jar in the lib directory, with MyInterceptor class, and a deployed jar with two ejbs (MyRegularUser and CallingRegularUser) and a local interceptor (MyLocalInterceptor).
> The CallingRegularUser depends on MyRegularUser ejb, and on the post process method it calls a method of MyRegularUser.
> When called, both MyLocalInterceptor and MyInterceptor should run, but only MyLocalInterceptor runs.
> The log:
> [oourfali at dhcp-1-30 bin]$  ./standalone.sh --server-config=standalone-preview.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/tlv/oourfali/jboss-7.0.0.CR1
>   JAVA: /usr/java/jdk1.6.0_24/bin/java
>   JAVA_OPTS: -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 -Xrunjdwp:transport=dt_socket,address=7766,server=y,suspend=n
> =========================================================================
> Listening for transport dt_socket at address: 7766
> 12:46:21,780 INFO  [org.jboss.modules] JBoss Modules version 1.0.0.CR4
> 12:46:22,027 INFO  [org.jboss.msc] JBoss MSC version 1.0.0.CR2
> 12:46:22,083 INFO  [org.jboss.as] JBoss AS 7.0.0.CR1 "White Rabbit" starting
> 12:46:23,065 INFO  [org.jboss.as] creating http management service using network interface (management) port (9990) securePort (-1)
> 12:46:23,077 INFO  [org.jboss.as.logging] Removing bootstrap log handlers
> 12:46:23,095 INFO  [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying JDBC-compliant driver class org.h2.Driver (version 1.2)
> 12:46:23,101 INFO  [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 9.0)
> 12:46:23,187 INFO  [org.jboss.as.jacorb] (Controller Boot Thread) Activating JacORB Subsystem
> 12:46:23,319 INFO  [org.jboss.as.naming] (Controller Boot Thread) Activating Naming Subsystem
> 12:46:23,333 INFO  [org.jboss.as.naming] (MSC service thread 1-1) Starting Naming Service 
> 12:46:23,344 INFO  [org.jboss.as.osgi] (Controller Boot Thread) Activating OSGi Subsystem
> 12:46:23,364 INFO  [org.jboss.as.security] (Controller Boot Thread) Activating Security Subsystem
> 12:46:23,372 INFO  [org.jboss.remoting] (MSC service thread 1-5) JBoss Remoting version 3.2.0.Beta2
> 12:46:23,388 INFO  [org.xnio] (MSC service thread 1-5) XNIO Version 3.0.0.Beta3
> 12:46:23,405 INFO  [org.xnio.nio] (MSC service thread 1-5) XNIO NIO Implementation Version 3.0.0.Beta3
> 12:46:23,522 INFO  [org.jboss.as.webservices] (Controller Boot Thread) Activating WebServices Extension
> 12:46:23,527 INFO  [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-8) The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/java/jdk1.6.0_24/jre/lib/amd64/server:/usr/java/jdk1.6.0_24/jre/lib/amd64:/usr/java/jdk1.6.0_24/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
> 12:46:23,605 INFO  [org.jboss.as.remoting] (MSC service thread 1-8) Listening on /10.35.203.35:9999
> 12:46:23,607 INFO  [org.jboss.as.jmx.JMXConnectorService] (MSC service thread 1-6) Starting remote JMX connector
> 12:46:23,628 INFO  [org.jboss.as.ee] (Controller Boot Thread) Activating EE subsystem
> 12:46:23,659 WARN  [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-5) Unable to set the URLStreamHandlerFactory
> 12:46:23,667 WARN  [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-5) Unable to set the ContentHandlerFactory
> 12:46:23,821 INFO  [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-7) JBoss Web Services - Stack CXF Server 4.0.0.Beta2
> 12:46:23,829 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-3) Starting Coyote HTTP/1.1 on http-vpn-203-35.tlv.redhat.com-10.35.203.35-8080
> 12:46:23,856 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-7) live server is starting with configuration HornetQ Configuration (clustered=false,backup=false,sharedStore=true,journalDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messagingjournal,bindingsDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messagingbindings,largeMessagesDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messaginglargemessages,pagingDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messagingpaging)
> 12:46:24,001 INFO  [org.jboss.as.connector] (MSC service thread 1-3) Starting JCA Subsystem (JBoss IronJacamar 1.0.0.CR2)
> 12:46:24,099 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) Bound data source [java:jboss/datasources/ExampleDS]
> 12:46:24,140 INFO  [org.jboss.as.jacorb] (MSC service thread 1-4) CORBA ORB Service Started
> 12:46:24,143 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) Bound data source [java:/RHEVMDataSource]
> 12:46:24,176 INFO  [org.jboss.as.connector.services.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-8) Registered connection factory java:/JmsXA on mdr
> 12:46:24,197 INFO  [org.hornetq.ra.HornetQResourceAdapter] (MSC service thread 1-8) HornetQ resource adaptor started
> 12:46:24,197 INFO  [org.jboss.as.connector.services.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-8) IJ020002: Deployed: file://RaActivatorhornetq-ra
> 12:46:24,350 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-7) Started Netty Acceptor version 3.2.3.Final-r${buildNumber} vpn-203-35.tlv.redhat.com:5455 for CORE protocol
> 12:46:24,365 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-7) Started Netty Acceptor version 3.2.3.Final-r${buildNumber} vpn-203-35.tlv.redhat.com:5445 for CORE protocol
> 12:46:24,381 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-7) Server is now live
> 12:46:24,381 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-7) HornetQ Server version 2.2.6.Final (HQ_2_2_6_FINAL_AS7, 121) [81345b0c-a929-11e0-850e-001a4aebfff4] started
> 12:46:24,384 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-2) trying to deploy queue jms.queue.testQueue
> 12:46:24,402 INFO  [org.jboss.as.jacorb] (MSC service thread 1-1) CORBA Naming Service Started
> 12:46:24,543 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-6) trying to deploy queue jms.topic.testTopic
> 12:46:24,806 INFO  [org.jboss.as.deployment] (MSC service thread 1-2) Started FileSystemDeploymentService for directory /home/tlv/oourfali/jboss-7.0.0.CR1/standalone/deployments
> 12:46:24,812 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found reproduction.ear in deployment directory. To trigger deployment create a file called reproduction.ear.dodeploy
> 12:46:24,812 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found rhevm-genericapi.war in deployment directory. To trigger deployment create a file called rhevm-genericapi.war.dodeploy
> 12:46:24,812 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found rhevm-genericapi.jar in deployment directory. To trigger deployment create a file called rhevm-genericapi.jar.dodeploy
> 12:46:24,813 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found rhevm.ear in deployment directory. To trigger deployment create a file called rhevm.ear.dodeploy
> 12:46:24,824 INFO  [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.0.CR1 "White Rabbit" started in 3253ms - Started 125 of 184 services (59 services are passive or on-demand)
> 12:46:24,842 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) Starting deployment of "reproduction.ear"
> 12:46:24,885 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) Starting deployment of "test_reg.jar"
> 12:46:24,973 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-8) JNDI bindings for session bean named CallingRegularUser in deployment unit subdeployment "test_reg.jar" of deployment "reproduction.ear" are as follows:
>         java:global/reproduction/test_reg/CallingRegularUser!reproduction.regular_user.CallingRegularUser
>         java:app/test_reg/CallingRegularUser!reproduction.regular_user.CallingRegularUser
>         java:module/CallingRegularUser!reproduction.regular_user.CallingRegularUser
>         java:global/reproduction/test_reg/CallingRegularUser
>         java:app/test_reg/CallingRegularUser
>         java:module/CallingRegularUser
> 12:46:24,973 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-8) JNDI bindings for session bean named MyRegularUser in deployment unit subdeployment "test_reg.jar" of deployment "reproduction.ear" are as follows:
>         java:global/reproduction/test_reg/MyRegularUser!reproduction.regular_user.MyRegularUser
>         java:app/test_reg/MyRegularUser!reproduction.regular_user.MyRegularUser
>         java:module/MyRegularUser!reproduction.regular_user.MyRegularUser
>         java:global/reproduction/test_reg/MyRegularUser
>         java:app/test_reg/MyRegularUser
>         java:module/MyRegularUser
> 12:46:25,069 INFO  [org.jboss.as.ejb3.deployment.processors.EjbDependsOnAnnotationProcessor] (MSC service thread 1-1) CallingRegularUser bean has @DependsOn
> 12:46:25,120 INFO  [stdout] (MSC service thread 1-6) My Regular User - initialized
> 12:46:25,122 INFO  [stdout] (MSC service thread 1-2) CallingRegularUser - calling initialized
> 12:46:25,129 WARN  [org.jboss.as.ejb3.component.EJBComponent] (MSC service thread 1-2) EJBTHREE-2120: deprecated getTransactionAttributeType method called (dev problem)
> 12:46:25,132 INFO  [stdout] (MSC service thread 1-2) local interceptor - testing
> 12:46:25,132 INFO  [stdout] (MSC service thread 1-2) MyRegularUser - doSomething
> 12:46:25,214 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 2) Deployed "reproduction.ear"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 10:15:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 15 Jul 2011 10:15:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1295) interceptors are
 ignored when they are in <ear>/lib
In-Reply-To: <1598263671.56012.1310725223676.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <379883372.56542.1310739324027.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on AS7-1295:
-----------------------------------

I'm closing this issue. But please reopen if you still this issue in AS7 Final. Thanks.

> interceptors are ignored when they are in <ear>/lib
> ---------------------------------------------------
>
>                 Key: AS7-1295
>                 URL: https://issues.jboss.org/browse/AS7-1295
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 7.0.0.Final
>         Environment: fedora 14
>            Reporter: Oved O
>            Assignee: David Lloyd
>         Attachments: reproduction.tar.gz
>
>
> When an ejb have interceptor classes from jars in <ear>/lib, those interceptors are ignored.
> For example (this example is attached), assuming you have a jar in the lib directory, with MyInterceptor class, and a deployed jar with two ejbs (MyRegularUser and CallingRegularUser) and a local interceptor (MyLocalInterceptor).
> The CallingRegularUser depends on MyRegularUser ejb, and on the post process method it calls a method of MyRegularUser.
> When called, both MyLocalInterceptor and MyInterceptor should run, but only MyLocalInterceptor runs.
> The log:
> [oourfali at dhcp-1-30 bin]$  ./standalone.sh --server-config=standalone-preview.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/tlv/oourfali/jboss-7.0.0.CR1
>   JAVA: /usr/java/jdk1.6.0_24/bin/java
>   JAVA_OPTS: -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 -Xrunjdwp:transport=dt_socket,address=7766,server=y,suspend=n
> =========================================================================
> Listening for transport dt_socket at address: 7766
> 12:46:21,780 INFO  [org.jboss.modules] JBoss Modules version 1.0.0.CR4
> 12:46:22,027 INFO  [org.jboss.msc] JBoss MSC version 1.0.0.CR2
> 12:46:22,083 INFO  [org.jboss.as] JBoss AS 7.0.0.CR1 "White Rabbit" starting
> 12:46:23,065 INFO  [org.jboss.as] creating http management service using network interface (management) port (9990) securePort (-1)
> 12:46:23,077 INFO  [org.jboss.as.logging] Removing bootstrap log handlers
> 12:46:23,095 INFO  [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying JDBC-compliant driver class org.h2.Driver (version 1.2)
> 12:46:23,101 INFO  [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 9.0)
> 12:46:23,187 INFO  [org.jboss.as.jacorb] (Controller Boot Thread) Activating JacORB Subsystem
> 12:46:23,319 INFO  [org.jboss.as.naming] (Controller Boot Thread) Activating Naming Subsystem
> 12:46:23,333 INFO  [org.jboss.as.naming] (MSC service thread 1-1) Starting Naming Service 
> 12:46:23,344 INFO  [org.jboss.as.osgi] (Controller Boot Thread) Activating OSGi Subsystem
> 12:46:23,364 INFO  [org.jboss.as.security] (Controller Boot Thread) Activating Security Subsystem
> 12:46:23,372 INFO  [org.jboss.remoting] (MSC service thread 1-5) JBoss Remoting version 3.2.0.Beta2
> 12:46:23,388 INFO  [org.xnio] (MSC service thread 1-5) XNIO Version 3.0.0.Beta3
> 12:46:23,405 INFO  [org.xnio.nio] (MSC service thread 1-5) XNIO NIO Implementation Version 3.0.0.Beta3
> 12:46:23,522 INFO  [org.jboss.as.webservices] (Controller Boot Thread) Activating WebServices Extension
> 12:46:23,527 INFO  [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-8) The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/java/jdk1.6.0_24/jre/lib/amd64/server:/usr/java/jdk1.6.0_24/jre/lib/amd64:/usr/java/jdk1.6.0_24/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
> 12:46:23,605 INFO  [org.jboss.as.remoting] (MSC service thread 1-8) Listening on /10.35.203.35:9999
> 12:46:23,607 INFO  [org.jboss.as.jmx.JMXConnectorService] (MSC service thread 1-6) Starting remote JMX connector
> 12:46:23,628 INFO  [org.jboss.as.ee] (Controller Boot Thread) Activating EE subsystem
> 12:46:23,659 WARN  [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-5) Unable to set the URLStreamHandlerFactory
> 12:46:23,667 WARN  [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-5) Unable to set the ContentHandlerFactory
> 12:46:23,821 INFO  [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-7) JBoss Web Services - Stack CXF Server 4.0.0.Beta2
> 12:46:23,829 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-3) Starting Coyote HTTP/1.1 on http-vpn-203-35.tlv.redhat.com-10.35.203.35-8080
> 12:46:23,856 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-7) live server is starting with configuration HornetQ Configuration (clustered=false,backup=false,sharedStore=true,journalDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messagingjournal,bindingsDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messagingbindings,largeMessagesDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messaginglargemessages,pagingDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messagingpaging)
> 12:46:24,001 INFO  [org.jboss.as.connector] (MSC service thread 1-3) Starting JCA Subsystem (JBoss IronJacamar 1.0.0.CR2)
> 12:46:24,099 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) Bound data source [java:jboss/datasources/ExampleDS]
> 12:46:24,140 INFO  [org.jboss.as.jacorb] (MSC service thread 1-4) CORBA ORB Service Started
> 12:46:24,143 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) Bound data source [java:/RHEVMDataSource]
> 12:46:24,176 INFO  [org.jboss.as.connector.services.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-8) Registered connection factory java:/JmsXA on mdr
> 12:46:24,197 INFO  [org.hornetq.ra.HornetQResourceAdapter] (MSC service thread 1-8) HornetQ resource adaptor started
> 12:46:24,197 INFO  [org.jboss.as.connector.services.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-8) IJ020002: Deployed: file://RaActivatorhornetq-ra
> 12:46:24,350 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-7) Started Netty Acceptor version 3.2.3.Final-r${buildNumber} vpn-203-35.tlv.redhat.com:5455 for CORE protocol
> 12:46:24,365 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-7) Started Netty Acceptor version 3.2.3.Final-r${buildNumber} vpn-203-35.tlv.redhat.com:5445 for CORE protocol
> 12:46:24,381 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-7) Server is now live
> 12:46:24,381 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-7) HornetQ Server version 2.2.6.Final (HQ_2_2_6_FINAL_AS7, 121) [81345b0c-a929-11e0-850e-001a4aebfff4] started
> 12:46:24,384 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-2) trying to deploy queue jms.queue.testQueue
> 12:46:24,402 INFO  [org.jboss.as.jacorb] (MSC service thread 1-1) CORBA Naming Service Started
> 12:46:24,543 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-6) trying to deploy queue jms.topic.testTopic
> 12:46:24,806 INFO  [org.jboss.as.deployment] (MSC service thread 1-2) Started FileSystemDeploymentService for directory /home/tlv/oourfali/jboss-7.0.0.CR1/standalone/deployments
> 12:46:24,812 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found reproduction.ear in deployment directory. To trigger deployment create a file called reproduction.ear.dodeploy
> 12:46:24,812 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found rhevm-genericapi.war in deployment directory. To trigger deployment create a file called rhevm-genericapi.war.dodeploy
> 12:46:24,812 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found rhevm-genericapi.jar in deployment directory. To trigger deployment create a file called rhevm-genericapi.jar.dodeploy
> 12:46:24,813 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found rhevm.ear in deployment directory. To trigger deployment create a file called rhevm.ear.dodeploy
> 12:46:24,824 INFO  [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.0.CR1 "White Rabbit" started in 3253ms - Started 125 of 184 services (59 services are passive or on-demand)
> 12:46:24,842 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) Starting deployment of "reproduction.ear"
> 12:46:24,885 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) Starting deployment of "test_reg.jar"
> 12:46:24,973 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-8) JNDI bindings for session bean named CallingRegularUser in deployment unit subdeployment "test_reg.jar" of deployment "reproduction.ear" are as follows:
>         java:global/reproduction/test_reg/CallingRegularUser!reproduction.regular_user.CallingRegularUser
>         java:app/test_reg/CallingRegularUser!reproduction.regular_user.CallingRegularUser
>         java:module/CallingRegularUser!reproduction.regular_user.CallingRegularUser
>         java:global/reproduction/test_reg/CallingRegularUser
>         java:app/test_reg/CallingRegularUser
>         java:module/CallingRegularUser
> 12:46:24,973 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-8) JNDI bindings for session bean named MyRegularUser in deployment unit subdeployment "test_reg.jar" of deployment "reproduction.ear" are as follows:
>         java:global/reproduction/test_reg/MyRegularUser!reproduction.regular_user.MyRegularUser
>         java:app/test_reg/MyRegularUser!reproduction.regular_user.MyRegularUser
>         java:module/MyRegularUser!reproduction.regular_user.MyRegularUser
>         java:global/reproduction/test_reg/MyRegularUser
>         java:app/test_reg/MyRegularUser
>         java:module/MyRegularUser
> 12:46:25,069 INFO  [org.jboss.as.ejb3.deployment.processors.EjbDependsOnAnnotationProcessor] (MSC service thread 1-1) CallingRegularUser bean has @DependsOn
> 12:46:25,120 INFO  [stdout] (MSC service thread 1-6) My Regular User - initialized
> 12:46:25,122 INFO  [stdout] (MSC service thread 1-2) CallingRegularUser - calling initialized
> 12:46:25,129 WARN  [org.jboss.as.ejb3.component.EJBComponent] (MSC service thread 1-2) EJBTHREE-2120: deprecated getTransactionAttributeType method called (dev problem)
> 12:46:25,132 INFO  [stdout] (MSC service thread 1-2) local interceptor - testing
> 12:46:25,132 INFO  [stdout] (MSC service thread 1-2) MyRegularUser - doSomething
> 12:46:25,214 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 2) Deployed "reproduction.ear"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 10:15:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 15 Jul 2011 10:15:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-1295) interceptors are
 ignored when they are in <ear>/lib
In-Reply-To: <1598263671.56012.1310725223676.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2010521393.56548.1310739324581.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai closed AS7-1295.
-----------------------------

    Resolution: Out of Date


> interceptors are ignored when they are in <ear>/lib
> ---------------------------------------------------
>
>                 Key: AS7-1295
>                 URL: https://issues.jboss.org/browse/AS7-1295
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 7.0.0.Final
>         Environment: fedora 14
>            Reporter: Oved O
>            Assignee: David Lloyd
>         Attachments: reproduction.tar.gz
>
>
> When an ejb have interceptor classes from jars in <ear>/lib, those interceptors are ignored.
> For example (this example is attached), assuming you have a jar in the lib directory, with MyInterceptor class, and a deployed jar with two ejbs (MyRegularUser and CallingRegularUser) and a local interceptor (MyLocalInterceptor).
> The CallingRegularUser depends on MyRegularUser ejb, and on the post process method it calls a method of MyRegularUser.
> When called, both MyLocalInterceptor and MyInterceptor should run, but only MyLocalInterceptor runs.
> The log:
> [oourfali at dhcp-1-30 bin]$  ./standalone.sh --server-config=standalone-preview.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/tlv/oourfali/jboss-7.0.0.CR1
>   JAVA: /usr/java/jdk1.6.0_24/bin/java
>   JAVA_OPTS: -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 -Xrunjdwp:transport=dt_socket,address=7766,server=y,suspend=n
> =========================================================================
> Listening for transport dt_socket at address: 7766
> 12:46:21,780 INFO  [org.jboss.modules] JBoss Modules version 1.0.0.CR4
> 12:46:22,027 INFO  [org.jboss.msc] JBoss MSC version 1.0.0.CR2
> 12:46:22,083 INFO  [org.jboss.as] JBoss AS 7.0.0.CR1 "White Rabbit" starting
> 12:46:23,065 INFO  [org.jboss.as] creating http management service using network interface (management) port (9990) securePort (-1)
> 12:46:23,077 INFO  [org.jboss.as.logging] Removing bootstrap log handlers
> 12:46:23,095 INFO  [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying JDBC-compliant driver class org.h2.Driver (version 1.2)
> 12:46:23,101 INFO  [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 9.0)
> 12:46:23,187 INFO  [org.jboss.as.jacorb] (Controller Boot Thread) Activating JacORB Subsystem
> 12:46:23,319 INFO  [org.jboss.as.naming] (Controller Boot Thread) Activating Naming Subsystem
> 12:46:23,333 INFO  [org.jboss.as.naming] (MSC service thread 1-1) Starting Naming Service 
> 12:46:23,344 INFO  [org.jboss.as.osgi] (Controller Boot Thread) Activating OSGi Subsystem
> 12:46:23,364 INFO  [org.jboss.as.security] (Controller Boot Thread) Activating Security Subsystem
> 12:46:23,372 INFO  [org.jboss.remoting] (MSC service thread 1-5) JBoss Remoting version 3.2.0.Beta2
> 12:46:23,388 INFO  [org.xnio] (MSC service thread 1-5) XNIO Version 3.0.0.Beta3
> 12:46:23,405 INFO  [org.xnio.nio] (MSC service thread 1-5) XNIO NIO Implementation Version 3.0.0.Beta3
> 12:46:23,522 INFO  [org.jboss.as.webservices] (Controller Boot Thread) Activating WebServices Extension
> 12:46:23,527 INFO  [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-8) The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/java/jdk1.6.0_24/jre/lib/amd64/server:/usr/java/jdk1.6.0_24/jre/lib/amd64:/usr/java/jdk1.6.0_24/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
> 12:46:23,605 INFO  [org.jboss.as.remoting] (MSC service thread 1-8) Listening on /10.35.203.35:9999
> 12:46:23,607 INFO  [org.jboss.as.jmx.JMXConnectorService] (MSC service thread 1-6) Starting remote JMX connector
> 12:46:23,628 INFO  [org.jboss.as.ee] (Controller Boot Thread) Activating EE subsystem
> 12:46:23,659 WARN  [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-5) Unable to set the URLStreamHandlerFactory
> 12:46:23,667 WARN  [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-5) Unable to set the ContentHandlerFactory
> 12:46:23,821 INFO  [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-7) JBoss Web Services - Stack CXF Server 4.0.0.Beta2
> 12:46:23,829 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-3) Starting Coyote HTTP/1.1 on http-vpn-203-35.tlv.redhat.com-10.35.203.35-8080
> 12:46:23,856 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-7) live server is starting with configuration HornetQ Configuration (clustered=false,backup=false,sharedStore=true,journalDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messagingjournal,bindingsDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messagingbindings,largeMessagesDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messaginglargemessages,pagingDirectory=/home/tlv/oourfali/jboss-7.0.0.CR1/standalone/data/messagingpaging)
> 12:46:24,001 INFO  [org.jboss.as.connector] (MSC service thread 1-3) Starting JCA Subsystem (JBoss IronJacamar 1.0.0.CR2)
> 12:46:24,099 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) Bound data source [java:jboss/datasources/ExampleDS]
> 12:46:24,140 INFO  [org.jboss.as.jacorb] (MSC service thread 1-4) CORBA ORB Service Started
> 12:46:24,143 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) Bound data source [java:/RHEVMDataSource]
> 12:46:24,176 INFO  [org.jboss.as.connector.services.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-8) Registered connection factory java:/JmsXA on mdr
> 12:46:24,197 INFO  [org.hornetq.ra.HornetQResourceAdapter] (MSC service thread 1-8) HornetQ resource adaptor started
> 12:46:24,197 INFO  [org.jboss.as.connector.services.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-8) IJ020002: Deployed: file://RaActivatorhornetq-ra
> 12:46:24,350 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-7) Started Netty Acceptor version 3.2.3.Final-r${buildNumber} vpn-203-35.tlv.redhat.com:5455 for CORE protocol
> 12:46:24,365 INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-7) Started Netty Acceptor version 3.2.3.Final-r${buildNumber} vpn-203-35.tlv.redhat.com:5445 for CORE protocol
> 12:46:24,381 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-7) Server is now live
> 12:46:24,381 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-7) HornetQ Server version 2.2.6.Final (HQ_2_2_6_FINAL_AS7, 121) [81345b0c-a929-11e0-850e-001a4aebfff4] started
> 12:46:24,384 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-2) trying to deploy queue jms.queue.testQueue
> 12:46:24,402 INFO  [org.jboss.as.jacorb] (MSC service thread 1-1) CORBA Naming Service Started
> 12:46:24,543 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-6) trying to deploy queue jms.topic.testTopic
> 12:46:24,806 INFO  [org.jboss.as.deployment] (MSC service thread 1-2) Started FileSystemDeploymentService for directory /home/tlv/oourfali/jboss-7.0.0.CR1/standalone/deployments
> 12:46:24,812 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found reproduction.ear in deployment directory. To trigger deployment create a file called reproduction.ear.dodeploy
> 12:46:24,812 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found rhevm-genericapi.war in deployment directory. To trigger deployment create a file called rhevm-genericapi.war.dodeploy
> 12:46:24,812 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found rhevm-genericapi.jar in deployment directory. To trigger deployment create a file called rhevm-genericapi.jar.dodeploy
> 12:46:24,813 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found rhevm.ear in deployment directory. To trigger deployment create a file called rhevm.ear.dodeploy
> 12:46:24,824 INFO  [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.0.CR1 "White Rabbit" started in 3253ms - Started 125 of 184 services (59 services are passive or on-demand)
> 12:46:24,842 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) Starting deployment of "reproduction.ear"
> 12:46:24,885 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) Starting deployment of "test_reg.jar"
> 12:46:24,973 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-8) JNDI bindings for session bean named CallingRegularUser in deployment unit subdeployment "test_reg.jar" of deployment "reproduction.ear" are as follows:
>         java:global/reproduction/test_reg/CallingRegularUser!reproduction.regular_user.CallingRegularUser
>         java:app/test_reg/CallingRegularUser!reproduction.regular_user.CallingRegularUser
>         java:module/CallingRegularUser!reproduction.regular_user.CallingRegularUser
>         java:global/reproduction/test_reg/CallingRegularUser
>         java:app/test_reg/CallingRegularUser
>         java:module/CallingRegularUser
> 12:46:24,973 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-8) JNDI bindings for session bean named MyRegularUser in deployment unit subdeployment "test_reg.jar" of deployment "reproduction.ear" are as follows:
>         java:global/reproduction/test_reg/MyRegularUser!reproduction.regular_user.MyRegularUser
>         java:app/test_reg/MyRegularUser!reproduction.regular_user.MyRegularUser
>         java:module/MyRegularUser!reproduction.regular_user.MyRegularUser
>         java:global/reproduction/test_reg/MyRegularUser
>         java:app/test_reg/MyRegularUser
>         java:module/MyRegularUser
> 12:46:25,069 INFO  [org.jboss.as.ejb3.deployment.processors.EjbDependsOnAnnotationProcessor] (MSC service thread 1-1) CallingRegularUser bean has @DependsOn
> 12:46:25,120 INFO  [stdout] (MSC service thread 1-6) My Regular User - initialized
> 12:46:25,122 INFO  [stdout] (MSC service thread 1-2) CallingRegularUser - calling initialized
> 12:46:25,129 WARN  [org.jboss.as.ejb3.component.EJBComponent] (MSC service thread 1-2) EJBTHREE-2120: deprecated getTransactionAttributeType method called (dev problem)
> 12:46:25,132 INFO  [stdout] (MSC service thread 1-2) local interceptor - testing
> 12:46:25,132 INFO  [stdout] (MSC service thread 1-2) MyRegularUser - doSomething
> 12:46:25,214 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 2) Deployed "reproduction.ear"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 10:30:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Jul 2011 10:30:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1292) Cleanup xsd names for
 server config
In-Reply-To: <1797699218.55716.1310714783611.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <65400830.56667.1310740224370.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated AS7-1292:
----------------------------------

    Component/s: Domain Management
                     (was: Server)


> Cleanup xsd names for server config
> -----------------------------------
>
>                 Key: AS7-1292
>                 URL: https://issues.jboss.org/browse/AS7-1292
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.0.0.Final
>            Reporter: Wolfgang Knauf
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: 7.0.1.Final
>
>
> From a conversation on the dev mailing list beetween me and Brian: 
> >>> [Wolfgang] If my understanding is correct, the naming of the server config xsd
> >>> files is confusing, because a "jboss-7_0.xsd" will be something
> >>> different than "jboss_6_0.xsd".
> >>>
> >>
> >> [Brian] Yep. Kind of a big DOH!! moment. Looking at the jboss-metadata project
> >> where these deployment descriptor dtds/xsds come from, I see no
> >> jboss_6_0.xsd, just jboss_6_0.dtd. And no 7_0 xsd or dtd. But still,
> >> it's a naming conflict that's bound to bite us unless fixed.
> >>
> >> I recommend these server config xds all be renamed to
> >> jboss-as-XXX_1_0.xsd. They all have an xmlns of
> >> urn:jboss:domain:XXX:1.0, not 7.0, which IMO is fine since they may get
> >> revved independently of community AS releases.
> >>
> >
> >
> > [Wolfgang} Is there something more I should do - e.g. filing a JIRA issue? Or will
> > it be fixed by "miracle" ;-) or has someone this already on his todo list ?
> >
> [Brian] If you could file a JIRA and assign it to me, Fix Version 7.0.1.Final, I'd appreciate it. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 11:12:23 2011
From: jira-events at lists.jboss.org (Brad Davis (JIRA))
Date: Fri, 15 Jul 2011 11:12:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3141) Replace
 BinaryHeapPriorityQueue Implementation with Java's PriorityBlockingQueue
In-Reply-To: <436055328.52349.1310621003612.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <943882987.56963.1310742743851.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brad Davis commented on JBRULES-3141:
-------------------------------------

I have written a implementation that takes into account the following:
The number of different saliences should not be large in comparison to the number of activations themselves.

If N is the total number of activations... 
Before, the running time was essentially O ( log n ) for add and remove as the heap would have to be adjusted.

Now, I consider each salience a separate bucket.  So there may be N activations, but maybe a very small number of saliences S.
Now, the worst running time should be O ( log S ) + O ( 1 ).


> Replace BinaryHeapPriorityQueue Implementation with Java's PriorityBlockingQueue
> --------------------------------------------------------------------------------
>
>                 Key: JBRULES-3141
>                 URL: https://issues.jboss.org/browse/JBRULES-3141
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Brad Davis
>            Assignee: Brad Davis
>         Attachments: BasePriorityQueue.java, BinaryHeapPriorityQueueTest.java, IndexAwareQueue.java, SalienceAwareQueue.java
>
>
> Attached is a PriorityQueue implementation I wrote last night to replace our home grown implementation.  I think it must have preceded the PriorityBlockingQueue that is already part of Java 5 & 6.
> BinaryHeapPriorityQueueTest is where I plugged in this implementation.  Below are the results first running with our home grown BinaryHeapPriorityQueue, and then with the one I created, BasePriorityQueue.  There are numerous other benefits to using this as well, as it will fully implement the java.util.Collections API and therefore cleanup some other code elsewhere in our codebase.
> The result for 10000 objects inserted and retracted was: 
> BinaryHeapPriortyQueue
> elapsedEnqueue = 32
> elapsedDequeue = 294
> BasePriorityQueue
> elapsedEnqueue = 26
> elapsedDequeue = 167

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 11:12:23 2011
From: jira-events at lists.jboss.org (Brad Davis (JIRA))
Date: Fri, 15 Jul 2011 11:12:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-3141) Replace
 BinaryHeapPriorityQueue Implementation with Java's PriorityBlockingQueue
In-Reply-To: <436055328.52349.1310621003612.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1874472977.56966.1310742743951.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brad Davis updated JBRULES-3141:
--------------------------------

    Attachment: SalienceAwareQueue.java
                IndexAwareQueue.java


> Replace BinaryHeapPriorityQueue Implementation with Java's PriorityBlockingQueue
> --------------------------------------------------------------------------------
>
>                 Key: JBRULES-3141
>                 URL: https://issues.jboss.org/browse/JBRULES-3141
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Brad Davis
>            Assignee: Brad Davis
>         Attachments: BasePriorityQueue.java, BinaryHeapPriorityQueueTest.java, IndexAwareQueue.java, SalienceAwareQueue.java
>
>
> Attached is a PriorityQueue implementation I wrote last night to replace our home grown implementation.  I think it must have preceded the PriorityBlockingQueue that is already part of Java 5 & 6.
> BinaryHeapPriorityQueueTest is where I plugged in this implementation.  Below are the results first running with our home grown BinaryHeapPriorityQueue, and then with the one I created, BasePriorityQueue.  There are numerous other benefits to using this as well, as it will fully implement the java.util.Collections API and therefore cleanup some other code elsewhere in our codebase.
> The result for 10000 objects inserted and retracted was: 
> BinaryHeapPriortyQueue
> elapsedEnqueue = 32
> elapsedDequeue = 294
> BasePriorityQueue
> elapsedEnqueue = 26
> elapsedDequeue = 167

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 11:14:27 2011
From: jira-events at lists.jboss.org (Craig Ringer (JIRA))
Date: Fri, 15 Jul 2011 11:14:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1297) Weld claims to be
 able to inject Principal,
 but throws RuntimeException("not implemented") at runtime
Message-ID: <657543885.56986.1310742867765.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Weld claims to be able to inject Principal, but throws RuntimeException("not implemented") at runtime
-----------------------------------------------------------------------------------------------------

                 Key: AS7-1297
                 URL: https://issues.jboss.org/browse/AS7-1297
             Project: Application Server 7
          Issue Type: Bug
          Components: CDI / Weld, Security
    Affects Versions: 7.0.0.Final, 7.1.0.Alpha1
         Environment: Windows 7 x64, JDK 6 and 7 both tested. JBoss AS 7.0.0 release, and Jboss AS 7.1.0.Alpha1 nightly build 2011-07-15.
            Reporter: Craig Ringer
            Assignee: Stuart Douglas


In JBoss AS 7, Weld claims to be able to inject instances of  java.security.Principal. CDI archives that try to inject it do not fail at deployment time with unsatisfied dependencies. Instead, they fail later, at runtime, when injection is attempted. At this point a runtime exception indicating that principal injection isn't supported is thrown.

This prevents user code, or external frameworks like Seam 3 Security, from providing their own producers for javax.security.Principal without requiring a qualifier to be used. 

If JBoss AS 7's weld integration doesn't support container managed security yet (perhaps because container managed security is  not supported in JBoss AS 7 at all yet?) then it should not offer an injection point for the security principal.

Backtrace when calling toString() on an injected proxy for a Principal:

Caused by: java.lang.RuntimeException: not implemented
	at org.jboss.as.weld.services.bootstrap.WeldSecurityServices.getPrincipal(WeldSecurityServices.java:53)
	at org.jboss.weld.bean.builtin.ee.PrincipalBean$PrincipalCallable.call(PrincipalBean.java:48)
	at org.jboss.weld.bean.builtin.ee.PrincipalBean$PrincipalCallable.call(PrincipalBean.java:34)
	at org.jboss.weld.bean.builtin.CallableMethodHandler.invoke(CallableMethodHandler.java:50)
	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:62)
	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:125)
	at org.jboss.weld.security.Principal$1263393769$Proxy$_$$_Weld$Proxy$.toString(Principal$1263393769$Proxy$_$$_Weld$Proxy$.java)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 11:20:23 2011
From: jira-events at lists.jboss.org (Craig Ringer (JIRA))
Date: Fri, 15 Jul 2011 11:20:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1298) JBoss AS 7 doesn't
 appear to support container-managed security via web.xml and jboss-web.xml
Message-ID: <317987564.57015.1310743223751.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

JBoss AS 7 doesn't appear to support container-managed security via web.xml and jboss-web.xml
---------------------------------------------------------------------------------------------

                 Key: AS7-1298
                 URL: https://issues.jboss.org/browse/AS7-1298
             Project: Application Server 7
          Issue Type: Feature Request
    Affects Versions: 7.0.0.Final, 7.1.0.Alpha1
         Environment: n/a
            Reporter: Craig Ringer


There's no documentation for container-managed security in JBoss AS 7, and the schema for the main jboss config files and jboss-web.xml don't suggest any configuration mechanisms for JAAS realms, principal-to-user/group mappings, etc.

This is a significant limitation for apps porting from Glassfish 3, which expect to be able to access the current security principal from JNDI or inject it, and expect to be able to declare container-controlled access to particular URLs and different HTTP methods in web.xml.

Documenting this limitation in AS 7.0.0 would be a big improvement and would save porting time and hassle. Implementing support in a future version would, of course, be ideal.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 11:21:31 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 15 Jul 2011 11:21:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1299) Interface resource's
 criteria attribute should be read-write
Message-ID: <1146112164.57020.1310743291902.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Interface resource's criteria attribute should be read-write 
-------------------------------------------------------------

                 Key: AS7-1299
                 URL: https://issues.jboss.org/browse/AS7-1299
             Project: Application Server 7
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 7.0.0.Final
            Reporter: Brian Stansberry
             Fix For: 7.1.0.Alpha1


http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/003123.html

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 11:25:24 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 15 Jul 2011 11:25:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1298) JBoss AS 7 doesn't
 appear to support container-managed security via web.xml and jboss-web.xml
In-Reply-To: <317987564.57015.1310743223751.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1943014100.57036.1310743524026.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse reassigned AS7-1298:
-------------------------------------

    Assignee: Darran Lofthouse


> JBoss AS 7 doesn't appear to support container-managed security via web.xml and jboss-web.xml
> ---------------------------------------------------------------------------------------------
>
>                 Key: AS7-1298
>                 URL: https://issues.jboss.org/browse/AS7-1298
>             Project: Application Server 7
>          Issue Type: Feature Request
>    Affects Versions: 7.0.0.Final
>         Environment: n/a
>            Reporter: Craig Ringer
>            Assignee: Darran Lofthouse
>
> There's no documentation for container-managed security in JBoss AS 7, and the schema for the main jboss config files and jboss-web.xml don't suggest any configuration mechanisms for JAAS realms, principal-to-user/group mappings, etc.
> This is a significant limitation for apps porting from Glassfish 3, which expect to be able to access the current security principal from JNDI or inject it, and expect to be able to declare container-controlled access to particular URLs and different HTTP methods in web.xml.
> Documenting this limitation in AS 7.0.0 would be a big improvement and would save porting time and hassle. Implementing support in a future version would, of course, be ideal.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 11:25:24 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 15 Jul 2011 11:25:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1298) JBoss AS 7 doesn't
 appear to support container-managed security via web.xml and jboss-web.xml
In-Reply-To: <317987564.57015.1310743223751.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <272861435.57044.1310743524692.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated AS7-1298:
----------------------------------

    Affects Version/s:     (was: 7.1.0.Alpha1)


> JBoss AS 7 doesn't appear to support container-managed security via web.xml and jboss-web.xml
> ---------------------------------------------------------------------------------------------
>
>                 Key: AS7-1298
>                 URL: https://issues.jboss.org/browse/AS7-1298
>             Project: Application Server 7
>          Issue Type: Feature Request
>    Affects Versions: 7.0.0.Final
>         Environment: n/a
>            Reporter: Craig Ringer
>            Assignee: Darran Lofthouse
>
> There's no documentation for container-managed security in JBoss AS 7, and the schema for the main jboss config files and jboss-web.xml don't suggest any configuration mechanisms for JAAS realms, principal-to-user/group mappings, etc.
> This is a significant limitation for apps porting from Glassfish 3, which expect to be able to access the current security principal from JNDI or inject it, and expect to be able to declare container-controlled access to particular URLs and different HTTP methods in web.xml.
> Documenting this limitation in AS 7.0.0 would be a big improvement and would save porting time and hassle. Implementing support in a future version would, of course, be ideal.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 11:27:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 15 Jul 2011 11:27:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1298) JBoss AS 7 doesn't
 appear to support container-managed security via web.xml and jboss-web.xml
In-Reply-To: <317987564.57015.1310743223751.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1435237827.57051.1310743643703.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated AS7-1298:
----------------------------------

    Component/s: EJB
                 Security
                 Web
        Affects: [Documentation (Ref Guide, User Guide, etc.)]


> JBoss AS 7 doesn't appear to support container-managed security via web.xml and jboss-web.xml
> ---------------------------------------------------------------------------------------------
>
>                 Key: AS7-1298
>                 URL: https://issues.jboss.org/browse/AS7-1298
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: EJB, Security, Web
>    Affects Versions: 7.0.0.Final
>         Environment: n/a
>            Reporter: Craig Ringer
>            Assignee: Darran Lofthouse
>
> There's no documentation for container-managed security in JBoss AS 7, and the schema for the main jboss config files and jboss-web.xml don't suggest any configuration mechanisms for JAAS realms, principal-to-user/group mappings, etc.
> This is a significant limitation for apps porting from Glassfish 3, which expect to be able to access the current security principal from JNDI or inject it, and expect to be able to declare container-controlled access to particular URLs and different HTTP methods in web.xml.
> Documenting this limitation in AS 7.0.0 would be a big improvement and would save porting time and hassle. Implementing support in a future version would, of course, be ideal.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 11:37:23 2011
From: jira-events at lists.jboss.org (Craig Ringer (JIRA))
Date: Fri, 15 Jul 2011 11:37:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1298) JBoss AS 7 doesn't
 appear to support container-managed security via web.xml and jboss-web.xml
In-Reply-To: <317987564.57015.1310743223751.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <909465740.57087.1310744243697.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Craig Ringer commented on AS7-1298:
-----------------------------------

Note in particular https://docs.jboss.org/author/display/AS7/Security+Subsystem which says:

"When deploying applications to the JBoss Application Server most of the time it is likely that you would be deploying a web application or EJBs and just require a security domain to be defined with login modules to verify the users identity, this chapter aims to provider additional detail regarding the architecture and capability of the security subsystem however if you are just looking to define a security domain and leave the rest to the container please jump to ****************************. -- TODO"

Most of the rest is skeleton. So perhaps support is there, just not really documented, and with some significant limitations (https://issues.jboss.org/browse/AS7-1297). 

> JBoss AS 7 doesn't appear to support container-managed security via web.xml and jboss-web.xml
> ---------------------------------------------------------------------------------------------
>
>                 Key: AS7-1298
>                 URL: https://issues.jboss.org/browse/AS7-1298
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: EJB, Security, Web
>    Affects Versions: 7.0.0.Final
>         Environment: n/a
>            Reporter: Craig Ringer
>            Assignee: Darran Lofthouse
>
> There's no documentation for container-managed security in JBoss AS 7, and the schema for the main jboss config files and jboss-web.xml don't suggest any configuration mechanisms for JAAS realms, principal-to-user/group mappings, etc.
> This is a significant limitation for apps porting from Glassfish 3, which expect to be able to access the current security principal from JNDI or inject it, and expect to be able to declare container-controlled access to particular URLs and different HTTP methods in web.xml.
> Documenting this limitation in AS 7.0.0 would be a big improvement and would save porting time and hassle. Implementing support in a future version would, of course, be ideal.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 11:41:23 2011
From: jira-events at lists.jboss.org (Sebastian Wanio (JIRA))
Date: Fri, 15 Jul 2011 11:41:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1300) Management console
 doesn't work after changing management interface port
Message-ID: <1695801765.57097.1310744483645.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Management console doesn't work after changing management interface port
------------------------------------------------------------------------

                 Key: AS7-1300
                 URL: https://issues.jboss.org/browse/AS7-1300
             Project: Application Server 7
          Issue Type: Bug
          Components: Console
    Affects Versions: 7.0.0.Final
            Reporter: Sebastian Wanio
            Assignee: Heiko Braun


After changing http management port in _host.xml_ console stops working. 
Changing it back to default 9990 fixes the issue. 

It seems it s GWT related and 9990 port is "hardcoded" in java script files. 
Every script named _32.cache.js_ in _modules\org\jboss\com\sun\httpserver\main\jboss-as-console-1.0.0.Beta13-resources.jar_ has some variable set to ':9990/'. (only one occurrence in a file)

After changing its value to match a new http management port in _host.xml_ (other than 9990) and repackaging of _jboss-as-console-1.0.0.Beta13-resources.jar_ console starts working again. 

_Note! Checked only on domain mode. Not testes in standalone._


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 11:49:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 15 Jul 2011 11:49:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1294) Don't inject into
 static fields/methods
In-Reply-To: <204098316.55797.1310715683666.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <848292811.57124.1310744963660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd commented on AS7-1294:
----------------------------------

Unless, of course it's an app client, in which case we must *always* inject into static fields.  Make sure this check exists at a high enough level so that we don't prevent it from working for app client.

> Don't inject into static fields/methods
> ---------------------------------------
>
>                 Key: AS7-1294
>                 URL: https://issues.jboss.org/browse/AS7-1294
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 7.0.0.Final
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> The Java EE6 spec, section EE.5.2.5 says:
> {quote}
> The field or method may have any access qualifier (public, private, etc.). For all classes except application client
> main classes, the fields or methods must not be static.
> {quote}
> Currently we even inject even into static fields/methods.
>  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 12:02:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 15 Jul 2011 12:02:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1293) JNDI Binding service
In-Reply-To: <91757685.55770.1310715325126.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1724083591.57171.1310745743689.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai updated AS7-1293:
------------------------------

           Priority: Major  (was: Critical)
        Component/s: Naming
    Forum Reference: http://community.jboss.org/message/615368#615368  (was: http://community.jboss.org/message/615368#615368)


> JNDI Binding service
> --------------------
>
>                 Key: AS7-1293
>                 URL: https://issues.jboss.org/browse/AS7-1293
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Naming
>    Affects Versions: 7.0.0.Final
>            Reporter: Quanlin Chen
>
> I was just been told that so far it's impossible to bind arbitrary objects into JNDI in JBOSS 7, so would you be able to create a common binding service so that it could be working the same way as using JMX in previous AS versions?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 13:47:23 2011
From: jira-events at lists.jboss.org (Andrew Rubinger (JIRA))
Date: Fri, 15 Jul 2011 13:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBOOT-134) Add ClassPool
	support
In-Reply-To: <1827748478.1273605506789.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <591677905.57413.1310752043719.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Andrew Rubinger updated JBBOOT-134:
-----------------------------------

      Fix Version/s:     (was: 2.1.0-alpha-6)
    Forum Reference: https://community.jboss.org/message/542040#542040  (was: https://community.jboss.org/message/542040#542040)


Reverted in 111762 due to errors in starting AS6.

> Add ClassPool support
> ---------------------
>
>                 Key: JBBOOT-134
>                 URL: https://issues.jboss.org/browse/JBBOOT-134
>             Project: JBoss Bootstrap
>          Issue Type: Feature Request
>          Components: impl-base
>            Reporter: Andrew Rubinger
>            Assignee: Andrew Rubinger
>
> Apply Kabir's work on optimization to reflection within MC/AS.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 13:47:23 2011
From: jira-events at lists.jboss.org (Andrew Rubinger (JIRA))
Date: Fri, 15 Jul 2011 13:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBOOT-137) Release
	2.1.0-alpha-6
Message-ID: <1993545219.57415.1310752043769.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Release 2.1.0-alpha-6
---------------------

                 Key: JBBOOT-137
                 URL: https://issues.jboss.org/browse/JBBOOT-137
             Project: JBoss Bootstrap
          Issue Type: Task
            Reporter: Andrew Rubinger
            Assignee: Andrew Rubinger
             Fix For: 2.1.0-alpha-6


Track commits to release 2.1.0-alpha-6

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 13:51:23 2011
From: jira-events at lists.jboss.org (Andrew Rubinger (JIRA))
Date: Fri, 15 Jul 2011 13:51:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBOOT-137) Release
	2.1.0-alpha-6
In-Reply-To: <1993545219.57415.1310752043769.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <648907274.57440.1310752283809.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Andrew Rubinger resolved JBBOOT-137.
------------------------------------

    Resolution: Done


> Release 2.1.0-alpha-6
> ---------------------
>
>                 Key: JBBOOT-137
>                 URL: https://issues.jboss.org/browse/JBBOOT-137
>             Project: JBoss Bootstrap
>          Issue Type: Task
>            Reporter: Andrew Rubinger
>            Assignee: Andrew Rubinger
>             Fix For: 2.1.0-alpha-6
>
>
> Track commits to release 2.1.0-alpha-6

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 14:11:23 2011
From: jira-events at lists.jboss.org (Andrew Rubinger (JIRA))
Date: Fri, 15 Jul 2011 14:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-9417) Upgrade to
 jboss-bootstrap 2.1.0-alpha-6
Message-ID: <1032322639.57496.1310753483969.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Upgrade to jboss-bootstrap 2.1.0-alpha-6
----------------------------------------

                 Key: JBAS-9417
                 URL: https://issues.jboss.org/browse/JBAS-9417
             Project: Legacy JBoss Application Server 6 
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Andrew Rubinger
            Assignee: Andrew Rubinger
             Fix For: 6.1.0




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 14:11:24 2011
From: jira-events at lists.jboss.org (Andrew Rubinger (JIRA))
Date: Fri, 15 Jul 2011 14:11:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-9417) Upgrade to
 jboss-bootstrap 2.1.0-alpha-6
In-Reply-To: <1032322639.57496.1310753483969.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1066045275.57505.1310753484250.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Andrew Rubinger resolved JBAS-9417.
-----------------------------------

    Resolution: Done


> Upgrade to jboss-bootstrap 2.1.0-alpha-6
> ----------------------------------------
>
>                 Key: JBAS-9417
>                 URL: https://issues.jboss.org/browse/JBAS-9417
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Andrew Rubinger
>            Assignee: Andrew Rubinger
>             Fix For: 6.1.0
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 14:35:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Fri, 15 Jul 2011 14:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1291) UserTransaction not
 exposed in JNDI
In-Reply-To: <1777564578.55712.1310714483625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <592797957.57546.1310754923652.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Juergen Zimmermann updated AS7-1291:
------------------------------------

    Summary: UserTransaction not exposed in JNDI  (was: UserTransaction not exposed in JDNI)


> UserTransaction not exposed in JNDI
> -----------------------------------
>
>                 Key: AS7-1291
>                 URL: https://issues.jboss.org/browse/AS7-1291
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Naming
>    Affects Versions: 7.0.0.Final
>         Environment: 7.1.0.Alpha1 Jenkins build 1402
>            Reporter: Juergen Zimmermann
>            Assignee: John Bailey
>
> In JBoss 6 UserTransaction was exposed in JNDI named as java:comp/UserTransaction. Thus an Arquillian test method could be encapsulated in one single transaction:
> * lookup() the UserTransaction
> * begin() inside @Before
> * commit() inside @After
> Unfortunately, JBoss 7 doesn't have a JNDI entry for UserTransaction.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 15:46:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 15 Jul 2011 15:46:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-566) Support for
 pluggable JPA providers
In-Reply-To: <282632663.33198.1300384486238.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <414004490.57733.1310759183747.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on AS7-566:
----------------------------------

Committed some changes here https://github.com/scottmarlow/jboss-as/commit/18633d5c1f7dcb8e6e7f135b171eddacbbe659a2 and https://github.com/scottmarlow/jboss-as/commit/6b9aef5eac3c1c97db6d8cff66b735cf6d2f0821

Am currently working on the Hibernate3 module for AS7.  If everything goes as planned, JPA applications that include a copy of Hibernate 3 jars, will need to add a dependency on the "org.jboss.as.jpa.hibernate3" module (as described in https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7).  This could be done by adding a MANIFEST.MF entry:
Dependencies: org.jboss.as.jpa.hibernate3

Or something like the above, depending on how this effort goes.  :-)



> Support for pluggable JPA providers
> -----------------------------------
>
>                 Key: AS7-566
>                 URL: https://issues.jboss.org/browse/AS7-566
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: JPA / Hibernate
>            Reporter: David Lloyd
>            Assignee: Scott Marlow
>             Fix For: 7.1.0.Alpha1
>
>
> Maybe we could have a service per persistence provider that is based on a configuration settings.
> Questions:
> 1.  Where do the persistent provider jars go in the system?  Should we deploy them somehow?
> 2.  Each persistence.xml specifies the javax.persistence.spi.PersistenceProvider class name (via provider element) that it will use (defaults to whatever the AS7 default persistence provider).  The persistence.xml also allows vendor properties to be specified.  We could have an optional property "org.jboss.jpa.provider.versionSpecifier" that matches a specific version of the provider.
> Is this the best way to allow different versions of persistence provider?
> 3.  How could we best dynamically build a ModuleDependency on a persistence provider jar that 
> could be injected into a deployment (perhaps from JPADependencyProcessor)?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 17:39:23 2011
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 15 Jul 2011 17:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-3128) Create a JON/RHQ
 plugin for Drools
In-Reply-To: <686968631.47090.1310431043615.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <644589011.57840.1310765963709.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Edson Tirelli resolved JBRULES-3128.
------------------------------------

    Resolution: Done


Applied to 5.2.x branch and master branch. I am closing this ticket. Any eventual changes/bug fixes will be worked under specific tickets.

> Create a JON/RHQ plugin for Drools
> ----------------------------------
>
>                 Key: JBRULES-3128
>                 URL: https://issues.jboss.org/browse/JBRULES-3128
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.2.0.Final
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.2.1.Final, 5.3.0.Beta1
>
>
> Create a fully functional JON/RHQ plugin for Drools based on the POC developed a few years ago. Use latest Drools and RHQ versions.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 17:39:23 2011
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 15 Jul 2011 17:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-3128) Create a JON/RHQ
 plugin for Drools
In-Reply-To: <686968631.47090.1310431043615.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2104830710.57843.1310765963772.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Edson Tirelli closed JBRULES-3128.
----------------------------------



> Create a JON/RHQ plugin for Drools
> ----------------------------------
>
>                 Key: JBRULES-3128
>                 URL: https://issues.jboss.org/browse/JBRULES-3128
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.2.0.Final
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.2.1.Final, 5.3.0.Beta1
>
>
> Create a fully functional JON/RHQ plugin for Drools based on the POC developed a few years ago. Use latest Drools and RHQ versions.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 17:45:23 2011
From: jira-events at lists.jboss.org (Aslak Knutsen (JIRA))
Date: Fri, 15 Jul 2011 17:45:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1174) Arquillian
 Containers can not undeploy Archives not deployed using the same Container
 instance
In-Reply-To: <1725209106.32833.1309624403620.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <684025891.57849.1310766323944.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Aslak Knutsen reassigned AS7-1174:
----------------------------------

    Assignee: Aslak Knutsen


> Arquillian Containers can not undeploy Archives not deployed using the same Container instance
> ----------------------------------------------------------------------------------------------
>
>                 Key: AS7-1174
>                 URL: https://issues.jboss.org/browse/AS7-1174
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 7.0.0.CR1
>            Reporter: Aslak Knutsen
>            Assignee: Aslak Knutsen
>
> The CommonDeployableContainer keeps a registry of deployed deployments and their unique id in memory between deploy and undeploy. So unless the deployment you try to undeploy was deployed using the same instance of the Container it can't be undeployed. 
> This cause problems for use of the Container in e.g. SeamForge or MavenPlugin, where the JVM is taken up and down between deploy/undeploy operations.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 17:45:24 2011
From: jira-events at lists.jboss.org (Aslak Knutsen (JIRA))
Date: Fri, 15 Jul 2011 17:45:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1152) Support Deployment
 introspection using ProtocolMetadata in the Arquillian Containers
In-Reply-To: <2024534842.29230.1309422683684.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <701775901.57858.1310766324180.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Aslak Knutsen reassigned AS7-1152:
----------------------------------

    Assignee: Aslak Knutsen


> Support Deployment introspection using ProtocolMetadata in the Arquillian Containers
> ------------------------------------------------------------------------------------
>
>                 Key: AS7-1152
>                 URL: https://issues.jboss.org/browse/AS7-1152
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Test Suite
>    Affects Versions: 7.0.0.CR1
>            Reporter: Aslak Knutsen
>            Assignee: Aslak Knutsen
>
> on deploy, the Arquillian Containers should return a ProtocolMetadata object that describes the content of the Deployment.
> e.g. Which HTTP contexts (ip/port) are there, which Servlets etc. 
> This can be used for injection of URL's to the Deployed context, e.g. @ArquillianResource(MyServlet.class) URL url;
> The same is used by the ServletProtocol to discover the correct web context to call to invoke the test (this does not currently work at all with AS7)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 17:45:24 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 15 Jul 2011 17:45:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1301) Update OSGi to be
 compatible with JBoss Modules 1.1 series
Message-ID: <970188.57854.1310766324068.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Update OSGi to be compatible with JBoss Modules 1.1 series
----------------------------------------------------------

                 Key: AS7-1301
                 URL: https://issues.jboss.org/browse/AS7-1301
             Project: Application Server 7
          Issue Type: Task
          Components: OSGi
            Reporter: David Lloyd
            Assignee: Thomas Diesler
             Fix For: 7.1.0.Alpha1


JBoss Modules 1.1 has two significant changes.  First, jaxpmodule is eliminated.  Second, the system module is no more - instead there's a dependency type for the system class loader.

I currently have an updated AS in my http://github.com/dmlloyd/jboss-as/tree/upgrades branch.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 17:45:24 2011
From: jira-events at lists.jboss.org (Aslak Knutsen (JIRA))
Date: Fri, 15 Jul 2011 17:45:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1156) The JMX-AS7 Protocol
 should default to Remote
In-Reply-To: <1969131305.29265.1309423343741.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1212026382.57860.1310766324231.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Aslak Knutsen reassigned AS7-1156:
----------------------------------

    Assignee: Aslak Knutsen


> The JMX-AS7 Protocol should default to Remote
> ---------------------------------------------
>
>                 Key: AS7-1156
>                 URL: https://issues.jboss.org/browse/AS7-1156
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Test Suite
>    Affects Versions: 7.0.0.CR1
>            Reporter: Aslak Knutsen
>            Assignee: Aslak Knutsen
>
> Currently the user has to provide this config for Arquillian to work with AS7
> {code}
>     <container qualifier="jboss7" default="true">
>         <protocol type="jmx-as7">
>             <property name="executionType">REMOTE</property>
>         </protocol>
>     </container>
> {code}
> With out that, they will get a nasty exception:
> {code}
> java.lang.reflect.UndeclaredThrowableException
> 	at $Proxy17.runTestMethodEmbedded(Unknown Source)
> 	at org.jboss.arquillian.protocol.jmx.JMXMethodExecutor.invoke(JMXMethodExecutor.java:78)
> 	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:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:616)
> 	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(
> {code}
> Since Embedded mode is currently not used at all, Remote should be default. Possible the protocol can figure this out on it's own at runtime.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 17:47:23 2011
From: jira-events at lists.jboss.org (Aslak Knutsen (JIRA))
Date: Fri, 15 Jul 2011 17:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1152) Support Deployment
 introspection using ProtocolMetadata in the Arquillian Containers
In-Reply-To: <2024534842.29230.1309422683684.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <522025269.57864.1310766443722.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Aslak Knutsen updated AS7-1152:
-------------------------------

    Fix Version/s: 7.0.1.Final


> Support Deployment introspection using ProtocolMetadata in the Arquillian Containers
> ------------------------------------------------------------------------------------
>
>                 Key: AS7-1152
>                 URL: https://issues.jboss.org/browse/AS7-1152
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Test Suite
>    Affects Versions: 7.0.0.CR1
>            Reporter: Aslak Knutsen
>            Assignee: Aslak Knutsen
>             Fix For: 7.0.1.Final
>
>
> on deploy, the Arquillian Containers should return a ProtocolMetadata object that describes the content of the Deployment.
> e.g. Which HTTP contexts (ip/port) are there, which Servlets etc. 
> This can be used for injection of URL's to the Deployed context, e.g. @ArquillianResource(MyServlet.class) URL url;
> The same is used by the ServletProtocol to discover the correct web context to call to invoke the test (this does not currently work at all with AS7)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 17:47:23 2011
From: jira-events at lists.jboss.org (Aslak Knutsen (JIRA))
Date: Fri, 15 Jul 2011 17:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1156) The JMX-AS7 Protocol
 should default to Remote
In-Reply-To: <1969131305.29265.1309423343741.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1219778247.57868.1310766443887.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Aslak Knutsen updated AS7-1156:
-------------------------------

    Fix Version/s: 7.0.1.Final


> The JMX-AS7 Protocol should default to Remote
> ---------------------------------------------
>
>                 Key: AS7-1156
>                 URL: https://issues.jboss.org/browse/AS7-1156
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Test Suite
>    Affects Versions: 7.0.0.CR1
>            Reporter: Aslak Knutsen
>            Assignee: Aslak Knutsen
>             Fix For: 7.0.1.Final
>
>
> Currently the user has to provide this config for Arquillian to work with AS7
> {code}
>     <container qualifier="jboss7" default="true">
>         <protocol type="jmx-as7">
>             <property name="executionType">REMOTE</property>
>         </protocol>
>     </container>
> {code}
> With out that, they will get a nasty exception:
> {code}
> java.lang.reflect.UndeclaredThrowableException
> 	at $Proxy17.runTestMethodEmbedded(Unknown Source)
> 	at org.jboss.arquillian.protocol.jmx.JMXMethodExecutor.invoke(JMXMethodExecutor.java:78)
> 	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:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:616)
> 	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(
> {code}
> Since Embedded mode is currently not used at all, Remote should be default. Possible the protocol can figure this out on it's own at runtime.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 17:47:23 2011
From: jira-events at lists.jboss.org (Aslak Knutsen (JIRA))
Date: Fri, 15 Jul 2011 17:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1174) Arquillian Containers
 can not undeploy Archives not deployed using the same Container instance
In-Reply-To: <1725209106.32833.1309624403620.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <914132147.57870.1310766443949.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Aslak Knutsen updated AS7-1174:
-------------------------------

    Fix Version/s: 7.0.1.Final


> Arquillian Containers can not undeploy Archives not deployed using the same Container instance
> ----------------------------------------------------------------------------------------------
>
>                 Key: AS7-1174
>                 URL: https://issues.jboss.org/browse/AS7-1174
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 7.0.0.CR1
>            Reporter: Aslak Knutsen
>            Assignee: Aslak Knutsen
>             Fix For: 7.0.1.Final
>
>
> The CommonDeployableContainer keeps a registry of deployed deployments and their unique id in memory between deploy and undeploy. So unless the deployment you try to undeploy was deployed using the same instance of the Container it can't be undeployed. 
> This cause problems for use of the Container in e.g. SeamForge or MavenPlugin, where the JVM is taken up and down between deploy/undeploy operations.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 17:49:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 15 Jul 2011 17:49:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1302) Present a version of
 JAXP to use as an endorsed library
Message-ID: <2038466878.57873.1310766563632.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Present a version of JAXP to use as an endorsed library
-------------------------------------------------------

                 Key: AS7-1302
                 URL: https://issues.jboss.org/browse/AS7-1302
             Project: Application Server 7
          Issue Type: Task
          Components: XML Frameworks
            Reporter: David Lloyd
            Assignee: Jason Greene
             Fix For: 7.1.0.Alpha1


With JBoss Modules 1.1, the "jaxpmodule" facility has been eliminated.  Instead we will take a simpler approach: simply endorse a JAXP API family of our own.

The following tasks are required:
# Provide a full JAXP implementation which covers all JAXP APIs
# Add a method or methods to these APIs which either:
#* allow the default provider for each API to be specified
#* allow a selector object for each API to be specified, which returns the appropriate implementation on request
# Modify AS startup to include these JARs in the endorsed path
# Modify the AS JAXP API modules to filter through to the system class path instead of packaging the JARs as modules
# Remove said packaging from build.xml
# Remove the AS JAXP implementation modules from build.xml and the build module repository

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 18:06:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 15 Jul 2011 18:06:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1302) Present a version
 of JAXP to use as an endorsed library
In-Reply-To: <2038466878.57873.1310766563632.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1034199389.57890.1310767583696.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd commented on AS7-1302:
----------------------------------

Use of the "jaxpmodule" flag was already eliminated in my https://github.com/dmlloyd/jboss-as/tree/upgrades branch.

> Present a version of JAXP to use as an endorsed library
> -------------------------------------------------------
>
>                 Key: AS7-1302
>                 URL: https://issues.jboss.org/browse/AS7-1302
>             Project: Application Server 7
>          Issue Type: Task
>          Components: XML Frameworks
>            Reporter: David Lloyd
>            Assignee: Jason Greene
>             Fix For: 7.1.0.Alpha1
>
>
> With JBoss Modules 1.1, the "jaxpmodule" facility has been eliminated.  Instead we will take a simpler approach: simply endorse a JAXP API family of our own.
> The following tasks are required:
> # Provide a full JAXP implementation which covers all JAXP APIs
> # Add a method or methods to these APIs which either:
> #* allow the default provider for each API to be specified
> #* allow a selector object for each API to be specified, which returns the appropriate implementation on request
> # Modify AS startup to include these JARs in the endorsed path
> # Modify the AS JAXP API modules to filter through to the system class path instead of packaging the JARs as modules
> # Remove said packaging from build.xml
> # Remove the AS JAXP implementation modules from build.xml and the build module repository

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 20:49:23 2011
From: jira-events at lists.jboss.org (Cloves Almeida (JIRA))
Date: Fri, 15 Jul 2011 20:49:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-708) Ability to specify
 classloading exceptions to ignore similar to
 scanning-deployers-jboss-beans.xml
In-Reply-To: <76119589.26581.1304391198359.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1313978173.57964.1310777363814.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Cloves Almeida commented on AS7-708:
------------------------------------

The Vaadin JAR import classes on gwt-user (they have a justifiable use for that) that are only needed compile-time. Because of this error, one is unable to deploy Vaadin applications properly.

> Ability to specify classloading exceptions to ignore similar to scanning-deployers-jboss-beans.xml
> --------------------------------------------------------------------------------------------------
>
>                 Key: AS7-708
>                 URL: https://issues.jboss.org/browse/AS7-708
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: Jason Porter
>            Assignee: David Lloyd
>         Attachments: catch-demo.war
>
>
> We need to be able to specify exceptions to ignore during classpath scanning. This was available in AS6, we need it in AS7, or something similar. Please see https://issues.jboss.org/browse/SEAMFORGE-156

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 15 23:19:23 2011
From: jira-events at lists.jboss.org (Craig Ringer (JIRA))
Date: Fri, 15 Jul 2011 23:19:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1297) Weld claims to be
 able to inject Principal,
 but throws RuntimeException("not implemented") at runtime
In-Reply-To: <657543885.56986.1310742867765.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1847503699.58022.1310786363684.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Craig Ringer updated AS7-1297:
------------------------------

    Attachment: jbossas7-principal-injection.zip


Test case attached.

> Weld claims to be able to inject Principal, but throws RuntimeException("not implemented") at runtime
> -----------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1297
>                 URL: https://issues.jboss.org/browse/AS7-1297
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CDI / Weld, Security
>    Affects Versions: 7.0.0.Final, 7.1.0.Alpha1
>         Environment: Windows 7 x64, JDK 6 and 7 both tested. JBoss AS 7.0.0 release, and Jboss AS 7.1.0.Alpha1 nightly build 2011-07-15.
>            Reporter: Craig Ringer
>            Assignee: Stuart Douglas
>         Attachments: jbossas7-principal-injection.zip
>
>
> In JBoss AS 7, Weld claims to be able to inject instances of  java.security.Principal. CDI archives that try to inject it do not fail at deployment time with unsatisfied dependencies. Instead, they fail later, at runtime, when injection is attempted. At this point a runtime exception indicating that principal injection isn't supported is thrown.
> This prevents user code, or external frameworks like Seam 3 Security, from providing their own producers for javax.security.Principal without requiring a qualifier to be used. 
> If JBoss AS 7's weld integration doesn't support container managed security yet (perhaps because container managed security is  not supported in JBoss AS 7 at all yet?) then it should not offer an injection point for the security principal.
> Backtrace when calling toString() on an injected proxy for a Principal:
> Caused by: java.lang.RuntimeException: not implemented
> 	at org.jboss.as.weld.services.bootstrap.WeldSecurityServices.getPrincipal(WeldSecurityServices.java:53)
> 	at org.jboss.weld.bean.builtin.ee.PrincipalBean$PrincipalCallable.call(PrincipalBean.java:48)
> 	at org.jboss.weld.bean.builtin.ee.PrincipalBean$PrincipalCallable.call(PrincipalBean.java:34)
> 	at org.jboss.weld.bean.builtin.CallableMethodHandler.invoke(CallableMethodHandler.java:50)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:62)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:125)
> 	at org.jboss.weld.security.Principal$1263393769$Proxy$_$$_Weld$Proxy$.toString(Principal$1263393769$Proxy$_$$_Weld$Proxy$.java)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 00:54:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Sat, 16 Jul 2011 00:54:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-566) Support for
 pluggable JPA providers
In-Reply-To: <282632663.33198.1300384486238.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1848080399.58083.1310792063949.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on AS7-566:
----------------------------------

Will need a jboss-deployment-structure.xml rather than MANIFEST.MF entries.  Also need one more change for locating PersistenceProviderAdaptor implementations (the integration classes).  Will need a META-INF/services entry in each of the integration modules.

services/org.jboss.as.jpa.spi.PersistenceProviderAdaptor
org.jboss.as.jpa.hibernate3.HibernatePersistenceProviderAdaptor

<jboss-deployment-structure>
   <deployment>
        <exclusions>
          <module name="org.hibernate"/>
        </exclusions>
        <dependencies>
          <module name="org.jboss.as.jpa.hibernate3"/>
        </dependencies>
    </deployment>
</jboss-deployment-structure>


> Support for pluggable JPA providers
> -----------------------------------
>
>                 Key: AS7-566
>                 URL: https://issues.jboss.org/browse/AS7-566
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: JPA / Hibernate
>            Reporter: David Lloyd
>            Assignee: Scott Marlow
>             Fix For: 7.1.0.Alpha1
>
>
> Maybe we could have a service per persistence provider that is based on a configuration settings.
> Questions:
> 1.  Where do the persistent provider jars go in the system?  Should we deploy them somehow?
> 2.  Each persistence.xml specifies the javax.persistence.spi.PersistenceProvider class name (via provider element) that it will use (defaults to whatever the AS7 default persistence provider).  The persistence.xml also allows vendor properties to be specified.  We could have an optional property "org.jboss.jpa.provider.versionSpecifier" that matches a specific version of the provider.
> Is this the best way to allow different versions of persistence provider?
> 3.  How could we best dynamically build a ModuleDependency on a persistence provider jar that 
> could be injected into a deployment (perhaps from JPADependencyProcessor)?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 00:58:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Sat, 16 Jul 2011 00:58:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-566) Support
 for pluggable JPA providers
In-Reply-To: <282632663.33198.1300384486238.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1513617310.58089.1310792303789.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow edited comment on AS7-566 at 7/16/11 12:57 AM:
------------------------------------------------------------

Will need a jboss-deployment-structure.xml rather than MANIFEST.MF entries.  Also need one more change for locating PersistenceProviderAdaptor implementations (the integration classes).  Will need a META-INF/services entry in each of the integration modules.

jboss-as-jpa-hibernate3.jar/META-INF/services/org.jboss.as.jpa.spi.PersistenceProviderAdaptor will contain:
{quote}
org.jboss.as.jpa.hibernate3.HibernatePersistenceProviderAdaptor
{quote}

jboss-deployment-structure.xml will contain:
{code}
<jboss-deployment-structure>
   <deployment>
        <exclusions>
          <module name="org.hibernate"/>
        </exclusions>
        <dependencies>
          <module name="org.jboss.as.jpa.hibernate3"/>
        </dependencies>
    </deployment>
</jboss-deployment-structure>
{code}

      was (Author: smarlow):
    Will need a jboss-deployment-structure.xml rather than MANIFEST.MF entries.  Also need one more change for locating PersistenceProviderAdaptor implementations (the integration classes).  Will need a META-INF/services entry in each of the integration modules.

services/org.jboss.as.jpa.spi.PersistenceProviderAdaptor
org.jboss.as.jpa.hibernate3.HibernatePersistenceProviderAdaptor

<jboss-deployment-structure>
   <deployment>
        <exclusions>
          <module name="org.hibernate"/>
        </exclusions>
        <dependencies>
          <module name="org.jboss.as.jpa.hibernate3"/>
        </dependencies>
    </deployment>
</jboss-deployment-structure>

  
> Support for pluggable JPA providers
> -----------------------------------
>
>                 Key: AS7-566
>                 URL: https://issues.jboss.org/browse/AS7-566
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: JPA / Hibernate
>            Reporter: David Lloyd
>            Assignee: Scott Marlow
>             Fix For: 7.1.0.Alpha1
>
>
> Maybe we could have a service per persistence provider that is based on a configuration settings.
> Questions:
> 1.  Where do the persistent provider jars go in the system?  Should we deploy them somehow?
> 2.  Each persistence.xml specifies the javax.persistence.spi.PersistenceProvider class name (via provider element) that it will use (defaults to whatever the AS7 default persistence provider).  The persistence.xml also allows vendor properties to be specified.  We could have an optional property "org.jboss.jpa.provider.versionSpecifier" that matches a specific version of the provider.
> Is this the best way to allow different versions of persistence provider?
> 3.  How could we best dynamically build a ModuleDependency on a persistence provider jar that 
> could be injected into a deployment (perhaps from JPADependencyProcessor)?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 02:34:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 16 Jul 2011 02:34:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1291) UserTransaction not
 exposed in JNDI
In-Reply-To: <1777564578.55712.1310714483625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <914644962.58117.1310798063717.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on AS7-1291:
-----------------------------------

This appears more of a Arquillian question. The java:comp namespace is specific to components (like EJB, servlet etc...) and can only be used from within them. I don't know how Arquillian used to handle this in AS6. 

Assigning to Arquillian component.


> UserTransaction not exposed in JNDI
> -----------------------------------
>
>                 Key: AS7-1291
>                 URL: https://issues.jboss.org/browse/AS7-1291
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Naming
>    Affects Versions: 7.0.0.Final
>         Environment: 7.1.0.Alpha1 Jenkins build 1402
>            Reporter: Juergen Zimmermann
>            Assignee: John Bailey
>
> In JBoss 6 UserTransaction was exposed in JNDI named as java:comp/UserTransaction. Thus an Arquillian test method could be encapsulated in one single transaction:
> * lookup() the UserTransaction
> * begin() inside @Before
> * commit() inside @After
> Unfortunately, JBoss 7 doesn't have a JNDI entry for UserTransaction.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 02:36:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 16 Jul 2011 02:36:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1291) UserTransaction not
 exposed in JNDI
In-Reply-To: <1777564578.55712.1310714483625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1354327445.58122.1310798183656.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai updated AS7-1291:
------------------------------

       Assignee: Aslak Knutsen  (was: John Bailey)
    Component/s: Test Suite
                     (was: Naming)


> UserTransaction not exposed in JNDI
> -----------------------------------
>
>                 Key: AS7-1291
>                 URL: https://issues.jboss.org/browse/AS7-1291
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 7.0.0.Final
>         Environment: 7.1.0.Alpha1 Jenkins build 1402
>            Reporter: Juergen Zimmermann
>            Assignee: Aslak Knutsen
>
> In JBoss 6 UserTransaction was exposed in JNDI named as java:comp/UserTransaction. Thus an Arquillian test method could be encapsulated in one single transaction:
> * lookup() the UserTransaction
> * begin() inside @Before
> * commit() inside @After
> Unfortunately, JBoss 7 doesn't have a JNDI entry for UserTransaction.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 04:50:24 2011
From: jira-events at lists.jboss.org (Aslak Knutsen (JIRA))
Date: Sat, 16 Jul 2011 04:50:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1291) UserTransaction not
 exposed in JNDI
In-Reply-To: <1777564578.55712.1310714483625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1728066343.58159.1310806224046.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Aslak Knutsen reassigned AS7-1291:
----------------------------------

    Assignee: Andrew Rubinger  (was: Aslak Knutsen)


This should work when using e.g. the Servlet Protocol where the test request in coming in via a Servlet and your associated with the War comp. 

Default in AS7 the test execution is going via a jmx-service, which is executed outside of your own comp. This service has access to the test deployments Module and AS7 Core, and should be able to associate the correct comp during execution some how..

> UserTransaction not exposed in JNDI
> -----------------------------------
>
>                 Key: AS7-1291
>                 URL: https://issues.jboss.org/browse/AS7-1291
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 7.0.0.Final
>         Environment: 7.1.0.Alpha1 Jenkins build 1402
>            Reporter: Juergen Zimmermann
>            Assignee: Andrew Rubinger
>
> In JBoss 6 UserTransaction was exposed in JNDI named as java:comp/UserTransaction. Thus an Arquillian test method could be encapsulated in one single transaction:
> * lookup() the UserTransaction
> * begin() inside @Before
> * commit() inside @After
> Unfortunately, JBoss 7 doesn't have a JNDI entry for UserTransaction.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 04:56:23 2011
From: jira-events at lists.jboss.org (Aslak Knutsen (JIRA))
Date: Sat, 16 Jul 2011 04:56:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1303) TestNG not supported
 by Arquillian Service
Message-ID: <126901824.58167.1310806583835.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

TestNG not supported by Arquillian Service
------------------------------------------

                 Key: AS7-1303
                 URL: https://issues.jboss.org/browse/AS7-1303
             Project: Application Server 7
          Issue Type: Bug
          Components: Test Suite
    Affects Versions: 7.0.0.Final
            Reporter: Aslak Knutsen
            Assignee: Andrew Rubinger
            Priority: Critical
             Fix For: 7.0.1.Final


The Arquillian Service deployed during execution has a Deployment Processor hook to scan for "Test Deployments" so it can lookup the Module etc during execution. This scan assumes the TestDeployment will contain JUnits @RunWith annotation, which is true for JUnit, but not so much for other test frameworks. 

Arquillian is built to work with any test framework so TestNG/ScalaTest/Spock etc are all valid targets. 

Since the Arquillian Service is no longer a pre installed service, but deployed only during test execution, it could make sense to remove the scanning(used to filter out test deployment) and just consume all deployments during it's life time. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 04:56:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 16 Jul 2011 04:56:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1277) NPE when processing
 web.xml containing a <data-source/> element
In-Reply-To: <1170288922.52655.1310625816919.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1847238843.58165.1310806583787.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai updated AS7-1277:
------------------------------

       Fix Version/s: 7.0.1.Final
    Git Pull Request: https://github.com/jaikiran/jboss-as/commits/AS7-1277  (was: https://github.com/jaikiran/jboss-as/commits/AS7-1277)


> NPE when processing web.xml containing a <data-source/> element
> ---------------------------------------------------------------
>
>                 Key: AS7-1277
>                 URL: https://issues.jboss.org/browse/AS7-1277
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Final
>         Environment: Windows 7 Professional x64 SP1  (also reproduced on Fedora 15 x64 and Ubuntu 11.04 x86)
> JBoss AS 7 Final
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
>            Reporter: Craig Ringer
>            Assignee: jaikiran pai
>              Labels: data_source, datasource, deployment, persistence, web_xml
>             Fix For: 7.0.1.Final
>
>         Attachments: jboss-ds-defn-testcase.zip
>
>
> A webapp that uses the standard <data-source/> element to define a datasource within web.xml fails during the post-deploy step with the following backtrace:
> 14:38:18,717 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) Starting deployment of "dsmap2.war"
> 14:38:18,741 INFO  [org.jboss.jpa] (MSC service thread 1-6) read persistence.xml for org.example_dsmap2_war_1.0-SNAPSHOTPU
> 14:38:18,751 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC00001: Failed to start service jboss.deployment.unit."dsmap2.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."dsmap2.war".POST_MODULE: Failed to process phase POST_MODULE of deployment "dsmap2.war"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
> 	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_26]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.ee.datasource.DataSourceDefinitionDeploymentDescriptorParser.getBindingConfiguration(DataSourceDefinitionDeploymentDescriptorParser.java:101)
> 	at org.jboss.as.ee.datasource.DataSourceDefinitionDeploymentDescriptorParser.processDescriptorEntries(DataSourceDefinitionDeploymentDescriptorParser.java:58)
> 	at org.jboss.as.ee.component.AbstractDeploymentDescriptorBindingsProcessor.deploy(AbstractDeploymentDescriptorBindingsProcessor.java:60)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
> 	... 5 more
> A test case that uses a simple JavaDB database definition is attached. The test case deploys fine on Glassfish 3.1.1.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 05:13:23 2011
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Sat, 16 Jul 2011 05:13:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1291) UserTransaction not
 exposed in JNDI
In-Reply-To: <1777564578.55712.1310714483625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1316268723.58173.1310807603674.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

SBS JIRA Integration updated AS7-1291:
--------------------------------------

    Forum Reference: http://community.jboss.org/message/613087#613087


> UserTransaction not exposed in JNDI
> -----------------------------------
>
>                 Key: AS7-1291
>                 URL: https://issues.jboss.org/browse/AS7-1291
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 7.0.0.Final
>         Environment: 7.1.0.Alpha1 Jenkins build 1402
>            Reporter: Juergen Zimmermann
>            Assignee: Andrew Rubinger
>
> In JBoss 6 UserTransaction was exposed in JNDI named as java:comp/UserTransaction. Thus an Arquillian test method could be encapsulated in one single transaction:
> * lookup() the UserTransaction
> * begin() inside @Before
> * commit() inside @After
> Unfortunately, JBoss 7 doesn't have a JNDI entry for UserTransaction.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 05:49:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 16 Jul 2011 05:49:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-8810) Upgrade to
 jboss-logmanager 1.2.0.GA
In-Reply-To: <726365102.18561.1295283649839.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1503052138.58191.1310809764086.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai reassigned JBAS-8810:
----------------------------------

    Assignee: jaikiran pai  (was: David Lloyd)


> Upgrade to jboss-logmanager 1.2.0.GA
> ------------------------------------
>
>                 Key: JBAS-8810
>                 URL: https://issues.jboss.org/browse/JBAS-8810
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Component Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: David Lloyd
>            Assignee: jaikiran pai
>             Fix For: 6.1.0
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 05:49:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 16 Jul 2011 05:49:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-8810) Upgrade to
 jboss-logmanager 1.2.0.GA
In-Reply-To: <726365102.18561.1295283649839.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <668848154.58196.1310809764298.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai resolved JBAS-8810.
--------------------------------

    Resolution: Done


r111767 contains the upgrade

> Upgrade to jboss-logmanager 1.2.0.GA
> ------------------------------------
>
>                 Key: JBAS-8810
>                 URL: https://issues.jboss.org/browse/JBAS-8810
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Component Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: David Lloyd
>            Assignee: jaikiran pai
>             Fix For: 6.1.0
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 05:49:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 16 Jul 2011 05:49:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-8811) Upgrade to
 jboss-logging 3.0.0.GA
In-Reply-To: <342201952.18558.1295283649619.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <486851650.58200.1310809764386.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai reassigned JBAS-8811:
----------------------------------

    Assignee: jaikiran pai  (was: David Lloyd)


> Upgrade to jboss-logging 3.0.0.GA
> ---------------------------------
>
>                 Key: JBAS-8811
>                 URL: https://issues.jboss.org/browse/JBAS-8811
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Component Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: David Lloyd
>            Assignee: jaikiran pai
>             Fix For: 6.1.0
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 05:51:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 16 Jul 2011 05:51:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-8811) Upgrade to
 jboss-logging 3.0.0.GA
In-Reply-To: <342201952.18558.1295283649619.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <902325743.58204.1310809883765.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai resolved JBAS-8811.
--------------------------------

    Resolution: Done


r111767 contains the upgrade.

> Upgrade to jboss-logging 3.0.0.GA
> ---------------------------------
>
>                 Key: JBAS-8811
>                 URL: https://issues.jboss.org/browse/JBAS-8811
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Component Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: David Lloyd
>            Assignee: jaikiran pai
>             Fix For: 6.1.0
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 05:51:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 16 Jul 2011 05:51:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-8809) Upgrade to
 jboss-logmanager-log4j 1.0.0.GA
In-Reply-To: <200461042.18564.1295283650004.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <91912001.58209.1310809883945.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai reassigned JBAS-8809:
----------------------------------

    Assignee: jaikiran pai  (was: David Lloyd)


> Upgrade to jboss-logmanager-log4j 1.0.0.GA
> ------------------------------------------
>
>                 Key: JBAS-8809
>                 URL: https://issues.jboss.org/browse/JBAS-8809
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Component Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: David Lloyd
>            Assignee: jaikiran pai
>             Fix For: 6.1.0
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 05:51:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 16 Jul 2011 05:51:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-8809) Upgrade to
 jboss-logmanager-log4j 1.0.0.GA
In-Reply-To: <200461042.18564.1295283650004.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1117336025.58213.1310809884052.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai resolved JBAS-8809.
--------------------------------

    Resolution: Done


r111767 contains the upgrade

> Upgrade to jboss-logmanager-log4j 1.0.0.GA
> ------------------------------------------
>
>                 Key: JBAS-8809
>                 URL: https://issues.jboss.org/browse/JBAS-8809
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Component Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: David Lloyd
>            Assignee: jaikiran pai
>             Fix For: 6.1.0
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 05:51:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 16 Jul 2011 05:51:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-8819) Upgrade to log4j
	1.2.16
In-Reply-To: <1397310613.23204.1295449009615.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1058946350.58217.1310809884174.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai reassigned JBAS-8819:
----------------------------------

    Assignee: jaikiran pai  (was: David Lloyd)


> Upgrade to log4j 1.2.16
> -----------------------
>
>                 Key: JBAS-8819
>                 URL: https://issues.jboss.org/browse/JBAS-8819
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Component Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: David Lloyd
>            Assignee: jaikiran pai
>             Fix For: 6.1.0
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 05:51:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 16 Jul 2011 05:51:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-8819) Upgrade to log4j
	1.2.16
In-Reply-To: <1397310613.23204.1295449009615.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1135587547.58218.1310809884196.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai resolved JBAS-8819.
--------------------------------

    Resolution: Done


r111767 contains the upgrade.

> Upgrade to log4j 1.2.16
> -----------------------
>
>                 Key: JBAS-8819
>                 URL: https://issues.jboss.org/browse/JBAS-8819
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Component Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: David Lloyd
>            Assignee: jaikiran pai
>             Fix For: 6.1.0
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 05:53:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 16 Jul 2011 05:53:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-9407) Setting up of
 application specific logging context leads to IllegalArgumentException
In-Reply-To: <392148920.22068.1298291173604.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1167668340.58231.1310810004470.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai reassigned JBAS-9407:
----------------------------------

    Assignee: jaikiran pai  (was: David Lloyd)


> Setting up of application specific logging context leads to IllegalArgumentException 
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-9407
>                 URL: https://issues.jboss.org/browse/JBAS-9407
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>         Environment: JBoss AS 6.0.0.Final
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 6.1.0
>
>
> Many users have reported that trying to setup application specific logging context leads to IllegalArgumentException in JBoss AS 6.0.0.Final (please see the referenced forum thread for one such example). I tried a simple application (.war file with jboss-logging.xml in WEB-INF) with the following jboss-logging.xml file:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <!-- ===================================================================== -->
> <!--                                                                       -->
> <!--  Logging System Configuration                                         -->
> <!--                                                                       -->
> <!-- ===================================================================== -->
> <logging xmlns="urn:jboss:logging:6.0" xmlns:b="urn:jboss:bean-deployer:2.0" context="first">
> 	<!-- Define our logging context -->
> 		
> 	<define-context name="first"/>
>    <!-- A time/date based rolling handler -->
>    <periodic-rotating-file-handler
>          file-name="${jboss.server.log.dir}/first-app.log"
>          name="FILE"
>          autoflush="true"
>          append="false"
>          suffix=".yyyy-MM-dd">  <!-- To roll over at the top of each hour, use ".yyyy-MM-dd-HH" instead -->
>       <error-manager>
>          <only-once/>
>       </error-manager>
>       <formatter>
>          <!-- To revert back to simple stack traces without JAR versions, change "%E" to "%e" below. -->
>          <!-- Uncomment this to get the class name in the log as well as the category
>          <pattern-formatter pattern="%d %-5p [%c] %C{1} (%t) %s%E%n"/>
>          -->
>          <!-- Uncomment this to log without the class name in the log -->
>          <pattern-formatter pattern="%d %-5p [%c] (%t) %s%E%n"/>
>       </formatter>
>    </periodic-rotating-file-handler>
>    
>    
>    <!-- =============================================== -->
>    <!-- Limit categories                                -->
>    <!-- =============================================== -->
>    <!-- Limit the org.jboss category to DEBUG -->
>    <logger category="org.jboss">
>       <level name="TRACE"/>
>    </logger>
>    <logger category="org.myapp">
>       <level name="TRACE"/>
>    </logger>
>    
>    <!-- ======================= -->
>    <!-- Setup the Root category -->
>    <!-- ======================= -->
>    <root-logger>
>       <!-- Set the root logger priority via a system property, with a default value. -->
>       <level name="${jboss.server.log.threshold:INFO}"/>
>       <handlers>
>          <handler-ref name="FILE"/>
>       </handlers>
>    </root-logger>
> </logging>
> {code}
> There's nothing special about this jboss-logging.xml, except that it defines a application specific logging context. During deployment of this application, the server throws the following exception and the deployment fails:
> {code}
> 17:39:35,465 ERROR [AbstractKernelController] Error installing to Configured: name=Logging:REGISTRATION:first:Anonymous-0 state=Instantiated: java.lang.RuntimeException: Error configuring property: selector for Logging:REGISTRATION:first:Anonymous-0
> 	at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:112) [jboss-kernel.jar:2.2.0.GA]
> 	at org.jboss.kernel.plugins.dependency.ConfigureAction.setAttributes(ConfigureAction.java:85) [jboss-kernel.jar:2.2.0.GA]
> 	at org.jboss.kernel.plugins.dependency.ConfigureAction.installActionInternal(ConfigureAction.java:44) [jboss-kernel.jar:2.2.0.GA]
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.GA]
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:894) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:641) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:182) [:2.2.0.GA]
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:58) [:2.2.0.GA]
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) [:2.2.0.GA]
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.0.GA]
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.GA]
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.0.GA]
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.0.GA]
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1571) [:2.2.0.GA]
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.0.GA]
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.0.GA]
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.0.GA]
> 	at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.0.0.Final]
> 	at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:143) [:0.2.2]
> 	at org.jboss.profileservice.dependency.ProfileDeployAction.deploy(ProfileDeployAction.java:151) [:0.2.2]
> 	at org.jboss.profileservice.dependency.ProfileDeployAction.installActionInternal(ProfileDeployAction.java:94) [:0.2.2]
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.GA]
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.profileservice.dependency.ProfileActivationWrapper$BasicProfileActivation.start(ProfileActivationWrapper.java:190) [:0.2.2]
> 	at org.jboss.profileservice.dependency.ProfileActivationWrapper.start(ProfileActivationWrapper.java:87) [:0.2.2]
> 	at org.jboss.profileservice.dependency.ProfileActivationService.activateProfile(ProfileActivationService.java:215) [:0.2.2]
> 	at org.jboss.profileservice.dependency.ProfileActivationService.activate(ProfileActivationService.java:159) [:0.2.2]
> 	at org.jboss.profileservice.bootstrap.AbstractProfileServiceBootstrap.activate(AbstractProfileServiceBootstrap.java:112) [:0.2.2]
> 	at org.jboss.profileservice.resolver.BasicResolverFactory$ProfileResolverFacade.deploy(BasicResolverFactory.java:87) [:0.2.2]
> 	at org.jboss.profileservice.bootstrap.AbstractProfileServiceBootstrap.start(AbstractProfileServiceBootstrap.java:91) [:0.2.2]
> 	at org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceBootstrap.start(BasicProfileServiceBootstrap.java:132) [:6.0.0.Final]
> 	at org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceBootstrap.start(BasicProfileServiceBootstrap.java:56) [:6.0.0.Final]
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:827) [jboss-bootstrap-impl-base.jar:2.1.0-alpha-5]
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:417) [jboss-bootstrap-impl-base.jar:2.1.0-alpha-5]
> 	at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
> Caused by: java.lang.IllegalArgumentException: Wrong arguments. setSelector for target org.jboss.logging.metadata.ClassLoaderRegistrationHelper at 111fce expected=[org.jboss.logmanager.ClassLoaderLogContextSelector] actual=[org.jboss.logmanager.LogContextSelectorService]
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.handleErrors(ReflectionUtils.java:404) [jboss-reflect.jar:2.2.0.GA]
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:74) [jboss-reflect.jar:2.2.0.GA]
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.0.GA]
> 	at org.jboss.beans.info.plugins.DefaultPropertyInfo.set(DefaultPropertyInfo.java:143) [jboss-reflect.jar:2.2.0.GA]
> 	at org.jboss.beans.info.plugins.BeanInfoUtil.set(BeanInfoUtil.java:177) [jboss-reflect.jar:2.2.0.GA]
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.setProperty(AbstractBeanInfo.java:289) [jboss-reflect.jar:2.2.0.GA]
> 	at org.jboss.kernel.plugins.dependency.PropertyDispatchWrapper.execute(PropertyDispatchWrapper.java:114) [jboss-kernel.jar:2.2.0.GA]
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47) [jboss-kernel.jar:2.2.0.GA]
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:125) [jboss-kernel.jar:2.2.0.GA]
> 	at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:107) [jboss-kernel.jar:2.2.0.GA]
> 	... 64 more
> {code}
> Looking at the JBoss Logging code, this appears to be a bug. The LoggingMetaDataHelper has this piece of code:
> {code}
> if (! context.equals("system")) {
>             // if it's "system", then nothing special needs to be done.
>             // Otherwise create a bean representing the registration of the deployment unit's classloader with a new log context.
>             final BeanMetaDataBuilder builder = BeanMetaDataBuilder.createBuilder(new GetClassLoaderBeanMetaData(getAnonymousName(context, Kind.REGISTRATION), ClassLoaderRegistrationHelper.class.getName()));
>             builder.addPropertyMetaData("logContext", builder.createInject(getContextName(context)));
>             builder.addPropertyMetaData("selector", builder.createInject("JBossLogManagerContextSelectorService"));
>             beanMetaDataList.add(builder.getBeanMetaData());
>         }
> {code}
> As can be seen, a BeanMetaData is being constructed and a bean named "JBossLogManagerContextSelectorService" is being injected into a field of type LogContextSelector. However, the xml which defines this "JBossLogManagerContextSelectorService" sets up the JBossLogManagerContextSelectorService to be of a different "type":
> {code:xml}
> <!--
>      ~ These two beans define the per-classloader log context selector which allows per-deployment logging.  Since
>      ~ enabling this feature may have a performance impact in certain cases, it's started up lazily (on demand)
>      ~ when a separate log context is defined in a user deployment.
>      -->
>    <bean name="JBossLogManagerClassLoaderContextSelector" class="org.jboss.logmanager.ClassLoaderLogContextSelector"/>
>    <bean name="JBossLogManagerContextSelectorService" class="org.jboss.logmanager.LogContextSelectorService" mode="On Demand">
>       <property name="selector">
>          <inject bean="JBossLogManagerClassLoaderContextSelector"/>
>       </property>
>    </bean>
> {code}
> There are 2 ways to fix this, either fix the code to refer to the "selector" field of JBossLogManagerContextSelectorService (I guess the right approach) or rename the beans in the logmanager-jboss-beans.xml to make sure  JBossLogManagerContextSelectorService is of type LogContextSelector (I consider this a workaround).
>  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 05:53:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 16 Jul 2011 05:53:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-9407) Setting up of
 application specific logging context leads to IllegalArgumentException
In-Reply-To: <392148920.22068.1298291173604.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <574519596.58233.1310810004574.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai resolved JBAS-9407.
--------------------------------

    Fix Version/s: 6.1.0
       Resolution: Done


r111767 contains the fix.

> Setting up of application specific logging context leads to IllegalArgumentException 
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-9407
>                 URL: https://issues.jboss.org/browse/JBAS-9407
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>         Environment: JBoss AS 6.0.0.Final
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 6.1.0
>
>
> Many users have reported that trying to setup application specific logging context leads to IllegalArgumentException in JBoss AS 6.0.0.Final (please see the referenced forum thread for one such example). I tried a simple application (.war file with jboss-logging.xml in WEB-INF) with the following jboss-logging.xml file:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <!-- ===================================================================== -->
> <!--                                                                       -->
> <!--  Logging System Configuration                                         -->
> <!--                                                                       -->
> <!-- ===================================================================== -->
> <logging xmlns="urn:jboss:logging:6.0" xmlns:b="urn:jboss:bean-deployer:2.0" context="first">
> 	<!-- Define our logging context -->
> 		
> 	<define-context name="first"/>
>    <!-- A time/date based rolling handler -->
>    <periodic-rotating-file-handler
>          file-name="${jboss.server.log.dir}/first-app.log"
>          name="FILE"
>          autoflush="true"
>          append="false"
>          suffix=".yyyy-MM-dd">  <!-- To roll over at the top of each hour, use ".yyyy-MM-dd-HH" instead -->
>       <error-manager>
>          <only-once/>
>       </error-manager>
>       <formatter>
>          <!-- To revert back to simple stack traces without JAR versions, change "%E" to "%e" below. -->
>          <!-- Uncomment this to get the class name in the log as well as the category
>          <pattern-formatter pattern="%d %-5p [%c] %C{1} (%t) %s%E%n"/>
>          -->
>          <!-- Uncomment this to log without the class name in the log -->
>          <pattern-formatter pattern="%d %-5p [%c] (%t) %s%E%n"/>
>       </formatter>
>    </periodic-rotating-file-handler>
>    
>    
>    <!-- =============================================== -->
>    <!-- Limit categories                                -->
>    <!-- =============================================== -->
>    <!-- Limit the org.jboss category to DEBUG -->
>    <logger category="org.jboss">
>       <level name="TRACE"/>
>    </logger>
>    <logger category="org.myapp">
>       <level name="TRACE"/>
>    </logger>
>    
>    <!-- ======================= -->
>    <!-- Setup the Root category -->
>    <!-- ======================= -->
>    <root-logger>
>       <!-- Set the root logger priority via a system property, with a default value. -->
>       <level name="${jboss.server.log.threshold:INFO}"/>
>       <handlers>
>          <handler-ref name="FILE"/>
>       </handlers>
>    </root-logger>
> </logging>
> {code}
> There's nothing special about this jboss-logging.xml, except that it defines a application specific logging context. During deployment of this application, the server throws the following exception and the deployment fails:
> {code}
> 17:39:35,465 ERROR [AbstractKernelController] Error installing to Configured: name=Logging:REGISTRATION:first:Anonymous-0 state=Instantiated: java.lang.RuntimeException: Error configuring property: selector for Logging:REGISTRATION:first:Anonymous-0
> 	at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:112) [jboss-kernel.jar:2.2.0.GA]
> 	at org.jboss.kernel.plugins.dependency.ConfigureAction.setAttributes(ConfigureAction.java:85) [jboss-kernel.jar:2.2.0.GA]
> 	at org.jboss.kernel.plugins.dependency.ConfigureAction.installActionInternal(ConfigureAction.java:44) [jboss-kernel.jar:2.2.0.GA]
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.GA]
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:894) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:641) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:182) [:2.2.0.GA]
> 	at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:58) [:2.2.0.GA]
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) [:2.2.0.GA]
> 	at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.0.GA]
> 	at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.GA]
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.0.GA]
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.0.GA]
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1571) [:2.2.0.GA]
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.0.GA]
> 	at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.0.GA]
> 	at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.0.GA]
> 	at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.0.0.Final]
> 	at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:143) [:0.2.2]
> 	at org.jboss.profileservice.dependency.ProfileDeployAction.deploy(ProfileDeployAction.java:151) [:0.2.2]
> 	at org.jboss.profileservice.dependency.ProfileDeployAction.installActionInternal(ProfileDeployAction.java:94) [:0.2.2]
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.GA]
> 	at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.GA]
> 	at org.jboss.profileservice.dependency.ProfileActivationWrapper$BasicProfileActivation.start(ProfileActivationWrapper.java:190) [:0.2.2]
> 	at org.jboss.profileservice.dependency.ProfileActivationWrapper.start(ProfileActivationWrapper.java:87) [:0.2.2]
> 	at org.jboss.profileservice.dependency.ProfileActivationService.activateProfile(ProfileActivationService.java:215) [:0.2.2]
> 	at org.jboss.profileservice.dependency.ProfileActivationService.activate(ProfileActivationService.java:159) [:0.2.2]
> 	at org.jboss.profileservice.bootstrap.AbstractProfileServiceBootstrap.activate(AbstractProfileServiceBootstrap.java:112) [:0.2.2]
> 	at org.jboss.profileservice.resolver.BasicResolverFactory$ProfileResolverFacade.deploy(BasicResolverFactory.java:87) [:0.2.2]
> 	at org.jboss.profileservice.bootstrap.AbstractProfileServiceBootstrap.start(AbstractProfileServiceBootstrap.java:91) [:0.2.2]
> 	at org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceBootstrap.start(BasicProfileServiceBootstrap.java:132) [:6.0.0.Final]
> 	at org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceBootstrap.start(BasicProfileServiceBootstrap.java:56) [:6.0.0.Final]
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:827) [jboss-bootstrap-impl-base.jar:2.1.0-alpha-5]
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:417) [jboss-bootstrap-impl-base.jar:2.1.0-alpha-5]
> 	at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
> Caused by: java.lang.IllegalArgumentException: Wrong arguments. setSelector for target org.jboss.logging.metadata.ClassLoaderRegistrationHelper at 111fce expected=[org.jboss.logmanager.ClassLoaderLogContextSelector] actual=[org.jboss.logmanager.LogContextSelectorService]
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.handleErrors(ReflectionUtils.java:404) [jboss-reflect.jar:2.2.0.GA]
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:74) [jboss-reflect.jar:2.2.0.GA]
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.0.GA]
> 	at org.jboss.beans.info.plugins.DefaultPropertyInfo.set(DefaultPropertyInfo.java:143) [jboss-reflect.jar:2.2.0.GA]
> 	at org.jboss.beans.info.plugins.BeanInfoUtil.set(BeanInfoUtil.java:177) [jboss-reflect.jar:2.2.0.GA]
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.setProperty(AbstractBeanInfo.java:289) [jboss-reflect.jar:2.2.0.GA]
> 	at org.jboss.kernel.plugins.dependency.PropertyDispatchWrapper.execute(PropertyDispatchWrapper.java:114) [jboss-kernel.jar:2.2.0.GA]
> 	at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47) [jboss-kernel.jar:2.2.0.GA]
> 	at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:125) [jboss-kernel.jar:2.2.0.GA]
> 	at org.jboss.kernel.plugins.dependency.ConfigureAction.dispatchSetProperty(ConfigureAction.java:107) [jboss-kernel.jar:2.2.0.GA]
> 	... 64 more
> {code}
> Looking at the JBoss Logging code, this appears to be a bug. The LoggingMetaDataHelper has this piece of code:
> {code}
> if (! context.equals("system")) {
>             // if it's "system", then nothing special needs to be done.
>             // Otherwise create a bean representing the registration of the deployment unit's classloader with a new log context.
>             final BeanMetaDataBuilder builder = BeanMetaDataBuilder.createBuilder(new GetClassLoaderBeanMetaData(getAnonymousName(context, Kind.REGISTRATION), ClassLoaderRegistrationHelper.class.getName()));
>             builder.addPropertyMetaData("logContext", builder.createInject(getContextName(context)));
>             builder.addPropertyMetaData("selector", builder.createInject("JBossLogManagerContextSelectorService"));
>             beanMetaDataList.add(builder.getBeanMetaData());
>         }
> {code}
> As can be seen, a BeanMetaData is being constructed and a bean named "JBossLogManagerContextSelectorService" is being injected into a field of type LogContextSelector. However, the xml which defines this "JBossLogManagerContextSelectorService" sets up the JBossLogManagerContextSelectorService to be of a different "type":
> {code:xml}
> <!--
>      ~ These two beans define the per-classloader log context selector which allows per-deployment logging.  Since
>      ~ enabling this feature may have a performance impact in certain cases, it's started up lazily (on demand)
>      ~ when a separate log context is defined in a user deployment.
>      -->
>    <bean name="JBossLogManagerClassLoaderContextSelector" class="org.jboss.logmanager.ClassLoaderLogContextSelector"/>
>    <bean name="JBossLogManagerContextSelectorService" class="org.jboss.logmanager.LogContextSelectorService" mode="On Demand">
>       <property name="selector">
>          <inject bean="JBossLogManagerClassLoaderContextSelector"/>
>       </property>
>    </bean>
> {code}
> There are 2 ways to fix this, either fix the code to refer to the "selector" field of JBossLogManagerContextSelectorService (I guess the right approach) or rename the beans in the logmanager-jboss-beans.xml to make sure  JBossLogManagerContextSelectorService is of type LogContextSelector (I consider this a workaround).
>  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 06:00:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 16 Jul 2011 06:00:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-8791) log4j-appender
 seems not working in jboss-logging (AS6 final)
In-Reply-To: <1457088199.46973.1294394117934.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1800647121.58244.1310810424362.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai resolved JBAS-8791.
--------------------------------

    Resolution: Done


r111767 commit upgraded log4j to 1.2.16 version (along with other logging fixes) and that should fix this issue. To test the fix, the nightly builds are available here http://community.jboss.org/thread/161386

Marking this as resolved. Please reopen if it's still an issue.

> log4j-appender seems not working in jboss-logging (AS6 final)
> -------------------------------------------------------------
>
>                 Key: JBAS-8791
>                 URL: https://issues.jboss.org/browse/JBAS-8791
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: 6.0.0.Final
>            Reporter: Gregoire Botquin
>            Assignee: David Lloyd
>              Labels: jboss-logging, log4j, log4j-appender, logging
>             Fix For: 6.1.0
>
>         Attachments: JBAS-8791-1.zip
>
>
> We are using some custom logger based on log4j appenders. I made a jboss-logging.xml configuration but it seems that my log4j-appender doesn't log anything. I'm working in AS6 final version.
>  
> I made an example with a standard log4j appender (neither working). The category "com.sample" should be managed by the log4jappender. Every second the bean should write something, but nothing happens, the log file is not even created. I tried with other log4j loggers/ custom loggers and no success. 
>  
> When activating CONSOLE handler the logs are correctly written in console, but when only using the log4j-appender nothing happens after server started. 
> The configuration file seems correct (?), but can't unfortunately check it against a documentation yet. 
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> <logging xmlns="urn:jboss:logging:6.0" xmlns:b="urn:jboss:bean-deployer:2.0">
>  
>    <!-- ================================= -->
>    <!-- Preserve messages in a local file -->
>    <!-- ================================= -->
>  
>    <!-- A time/date based rolling handler -->
>  
>    <periodic-rotating-file-handler
>          file-name="${jboss.server.log.dir}/server.log"
>          name="FILE"
>          autoflush="true"
>          append="true"
>          suffix=".yyyy-MM-dd">  <!-- To roll over at the top of each hour, use ".yyyy-MM-dd-HH" instead -->
>  
>       <error-manager>
>          <only-once/>
>       </error-manager>
>  
>       <formatter>
>          <!-- To revert back to simple stack traces without JAR versions, change "%E" to "%e" below. -->
>          <!-- Uncomment this to get the class name in the log as well as the category
>          <pattern-formatter pattern="%d %-5p [%c] %C{1} (%t) %s%E%n"/>
>          -->
>          <!-- Uncomment this to log without the class name in the log -->
>          <pattern-formatter pattern="%d %-5p [%c] (%t) %s%E%n"/>
>       </formatter>
>    </periodic-rotating-file-handler>
>  
>    <!-- ============================== -->
>    <!-- Append messages to the console -->
>    <!-- ============================== -->
>  
>    <console-handler name="CONSOLE" autoflush="true" target="System.out">
>       <error-manager>
>          <only-once/>
>       </error-manager>
>  
>       <level name="INFO"/>
>  
>       <formatter>
>          <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] %s%E%n"/>
>       </formatter>
>    </console-handler>
>  
>  
>     <log4j-appender name="Log4jAppender" class="org.apache.log4j.DailyRollingFileAppender">
>       <error-manager>
>          <only-once/>
>       </error-manager>
>       <level name="DEBUG"/>
>       <properties>
>          <!-- <property name="directory">${jboss.server.log.dir}/</property>  -->
>          <property name="file">${jboss.server.log.dir}/log4j.log</property>
>          <property name="append">true</property>
>   <property name="datePattern">'.'yyyy-MM-dd</property>
>       </properties>
>       <formatter>
>          <pattern-formatter pattern="%d %-5p [%c] %m%n"/>
>       </formatter>
>   
>    </log4j-appender>
>   
>    <logger category="com.sample">
>     <level name="DEBUG"/>
>  <handlers>
>  <handler-ref name="Log4jAppender"/>
>  </handlers>
>    </logger>
>  
>    <!-- ======================= -->
>    <!-- Setup the Root category -->
>    <!-- ======================= -->
>  
>    <root-logger>
>       <!-- Set the root logger priority via a system property, with a default value. -->
>       <level name="${jboss.server.log.threshold:INFO}"/>
>       <handlers>
>          <handler-ref name="Log4jAppender"/>
>    
>          
>         
>          <!--
>   <handler-ref name="CONSOLE"/>
>   <handler-ref name="FILE"/>
>   -->
>       </handlers>
>    </root-logger>
>  
> </logging>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>  
> package com.sample;
>  
> import javax.ejb.Schedule;
> import javax.ejb.Stateless;
>  
> import org.apache.log4j.Logger;
>  
> //@Singleton
> @Stateless
> public class TestBean {
>   
>  public static final Logger LOG = Logger.getLogger(TestBean.class);
>   
>   
>  public TestBean(){
>  System.out.println("TestBean is instantiated and should write someting in the log file");
>  LOG.info("This is information log");
>  }
>   
>   
>     @Schedule(second="*/1", minute="*",hour="*", persistent=false)
>  public void writeSomething(){
>  System.out.println("This should write something in the log file at scheduled times");
>  LOG.info("This is scheduled information log");
>  }
>   
> }

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 06:06:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 16 Jul 2011 06:06:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-8813) Upgrade to
 slf4j-jboss-logmanager 1.0.0.GA
In-Reply-To: <1141062184.18567.1295283769595.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <793469644.58266.1310810783627.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on JBAS-8813:
------------------------------------

AS6 trunk already uses 1.0.2.GA of slf4j-jboss-logmanager. This JIRA probably is outdated.


> Upgrade to slf4j-jboss-logmanager 1.0.0.GA
> ------------------------------------------
>
>                 Key: JBAS-8813
>                 URL: https://issues.jboss.org/browse/JBAS-8813
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Component Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 6.1.0
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 06:14:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Sat, 16 Jul 2011 06:14:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-1291) UserTransaction not
	exposed in JNDI
In-Reply-To: <1777564578.55712.1310714483625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <960159409.58269.1310811263640.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Juergen Zimmermann closed AS7-1291.
-----------------------------------

    Resolution: Rejected


See http://community.jboss.org/thread/168952

> UserTransaction not exposed in JNDI
> -----------------------------------
>
>                 Key: AS7-1291
>                 URL: https://issues.jboss.org/browse/AS7-1291
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 7.0.0.Final
>         Environment: 7.1.0.Alpha1 Jenkins build 1402
>            Reporter: Juergen Zimmermann
>            Assignee: Andrew Rubinger
>
> In JBoss 6 UserTransaction was exposed in JNDI named as java:comp/UserTransaction. Thus an Arquillian test method could be encapsulated in one single transaction:
> * lookup() the UserTransaction
> * begin() inside @Before
> * commit() inside @After
> Unfortunately, JBoss 7 doesn't have a JNDI entry for UserTransaction.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 06:24:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 16 Jul 2011 06:24:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-8813) Upgrade to
 slf4j-jboss-logmanager 1.0.0.GA
In-Reply-To: <1141062184.18567.1295283769595.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1120777881.58275.1310811863632.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai updated JBAS-8813:
-------------------------------

    Comment: was deleted

(was: AS6 trunk already uses 1.0.2.GA of slf4j-jboss-logmanager. This JIRA probably is outdated.
)


> Upgrade to slf4j-jboss-logmanager 1.0.0.GA
> ------------------------------------------
>
>                 Key: JBAS-8813
>                 URL: https://issues.jboss.org/browse/JBAS-8813
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Component Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 6.1.0
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 06:34:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 16 Jul 2011 06:34:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-708) Ability to specify
 classloading exceptions to ignore similar to
 scanning-deployers-jboss-beans.xml
In-Reply-To: <76119589.26581.1304391198359.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1859857128.58280.1310812464001.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on AS7-708:
----------------------------------

Cloves, please open a forum thread here http://community.jboss.org/en/jbossas/as7_users?view=discussions with all the relevant details. The scanning-deployers-jboss-beans.xml approach of listing exceptions to be ignored, IMO, wasn't a good way to deal with it and it won't be reintroduced in AS7 (hopefully). 

We however might come up with a way to allow skipping certain classes/jars from being scanned. But we must first know what exactly you and others are running into, to come up with the right set of requirements before implementing such a feature. So please create a forum thread to discuss the Vaadin specific issue.


> Ability to specify classloading exceptions to ignore similar to scanning-deployers-jboss-beans.xml
> --------------------------------------------------------------------------------------------------
>
>                 Key: AS7-708
>                 URL: https://issues.jboss.org/browse/AS7-708
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: Jason Porter
>            Assignee: David Lloyd
>         Attachments: catch-demo.war
>
>
> We need to be able to specify exceptions to ignore during classpath scanning. This was available in AS6, we need it in AS7, or something similar. Please see https://issues.jboss.org/browse/SEAMFORGE-156

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 06:42:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 16 Jul 2011 06:42:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-8813) Upgrade to
 slf4j-jboss-logmanager 1.0.0.GA
In-Reply-To: <1141062184.18567.1295283769595.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1675988829.58290.1310812943670.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai resolved JBAS-8813.
--------------------------------

      Assignee: jaikiran pai  (was: David Lloyd)
    Resolution: Done


r111768 contains the upgrade.


> Upgrade to slf4j-jboss-logmanager 1.0.0.GA
> ------------------------------------------
>
>                 Key: JBAS-8813
>                 URL: https://issues.jboss.org/browse/JBAS-8813
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Component Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>            Reporter: David Lloyd
>            Assignee: jaikiran pai
>             Fix For: 6.1.0
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 06:45:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 16 Jul 2011 06:45:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-8797) Logging with SLF4J
 produces wrong output when using multiple parameters in format
In-Reply-To: <665498002.5582.1294763749631.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1575670075.58295.1310813123845.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on JBAS-8797:
------------------------------------

The comment in JBLOGGING-53 https://issues.jboss.org/browse/JBLOGGING-53?focusedCommentId=12573513&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12573513 says that this is fixed in slf4j-jboss-logmanager 1.0.0.CR5.

r111768 for JBAS-8813 upgrades slf4j-jboss-logmanager to 1.0.0.GA. So AS6 trunk should now have this fix. To test this, use the nightly build as explained here http://community.jboss.org/thread/161386.

Marking this issue as resolved.

> Logging with SLF4J produces wrong output when using multiple parameters in format
> ---------------------------------------------------------------------------------
>
>                 Key: JBAS-8797
>                 URL: https://issues.jboss.org/browse/JBAS-8797
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: 6.0.0.Final
>         Environment: Ubuntu Linux 64bit
>            Reporter: Jens Reimann
>            Assignee: David Lloyd
>             Fix For: 6.1.0
>
>
> Logging with SLF4J and passing parameters as Object[] produces wrong output in the JBoss log:
> e.g.: logger.debug ( "Logging - Level: {}, Action: {}, Result: {}, UserData: {}, Reference: {}/{}", new Object[] { level, action, result, data, referenceType, referenceId } );
> produces
> Logging - Level: <parameter #1 as Object[]>, Action: {}, Result: {}, ....
> It seems to me that instead of handling the Object[] that is passed as array is used later on as simple Object which reduces the provided parameters to 1 instead. There seems to be no problem with the log calls that take one or two objects (which are separate methods in SLF4J).
> I would consider it major since it scrambles all logging messages using the Object[] methods.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 06:45:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 16 Jul 2011 06:45:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-8797) Logging with SLF4J
 produces wrong output when using multiple parameters in format
In-Reply-To: <665498002.5582.1294763749631.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <27967599.58301.1310813124021.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai resolved JBAS-8797.
--------------------------------

      Assignee: jaikiran pai  (was: David Lloyd)
    Resolution: Done


> Logging with SLF4J produces wrong output when using multiple parameters in format
> ---------------------------------------------------------------------------------
>
>                 Key: JBAS-8797
>                 URL: https://issues.jboss.org/browse/JBAS-8797
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>    Affects Versions: 6.0.0.Final
>         Environment: Ubuntu Linux 64bit
>            Reporter: Jens Reimann
>            Assignee: jaikiran pai
>             Fix For: 6.1.0
>
>
> Logging with SLF4J and passing parameters as Object[] produces wrong output in the JBoss log:
> e.g.: logger.debug ( "Logging - Level: {}, Action: {}, Result: {}, UserData: {}, Reference: {}/{}", new Object[] { level, action, result, data, referenceType, referenceId } );
> produces
> Logging - Level: <parameter #1 as Object[]>, Action: {}, Result: {}, ....
> It seems to me that instead of handling the Object[] that is passed as array is used later on as simple Object which reduces the provided parameters to 1 instead. There seems to be no problem with the log calls that take one or two objects (which are separate methods in SLF4J).
> I would consider it major since it scrambles all logging messages using the Object[] methods.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 08:58:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 16 Jul 2011 08:58:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCLUSTER-296)
 DistributedTreeManager.list for root context results in a
 NullPointerException
Message-ID: <1538576481.58450.1310821103640.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

DistributedTreeManager.list for root context results in a NullPointerException
------------------------------------------------------------------------------

                 Key: JBCLUSTER-296
                 URL: https://issues.jboss.org/browse/JBCLUSTER-296
             Project: JBoss Clustering
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: HA-Server-Cache-ISPN
    Affects Versions: HA-Server-Cache-ISPN 1.0.0.Final 
            Reporter: jaikiran pai
            Assignee: Paul Ferraro


Invoking DistributedTreeManager.list on the root name, results in a NPE. Attached is a testcase patch which reproduces this issue. This issue causes an NPE when using the jmx-console in the "all" profile of JBoss AS. See JBAS-8867.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 09:00:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 16 Jul 2011 09:00:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCLUSTER-296)
 DistributedTreeManager.list for root context results in a
 NullPointerException
In-Reply-To: <1538576481.58450.1310821103640.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <162045836.58455.1310821224326.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai updated JBCLUSTER-296:
-----------------------------------

    Attachment: JBCLUSTER-296-testcase.patch


Attaching the testcase which reproduces this issue

> DistributedTreeManager.list for root context results in a NullPointerException
> ------------------------------------------------------------------------------
>
>                 Key: JBCLUSTER-296
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-296
>             Project: JBoss Clustering
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: HA-Server-Cache-ISPN
>    Affects Versions: HA-Server-Cache-ISPN 1.0.0.Final 
>            Reporter: jaikiran pai
>            Assignee: Paul Ferraro
>         Attachments: JBCLUSTER-296-testcase.patch
>
>
> Invoking DistributedTreeManager.list on the root name, results in a NPE. Attached is a testcase patch which reproduces this issue. This issue causes an NPE when using the jmx-console in the "all" profile of JBoss AS. See JBAS-8867.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 09:09:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 16 Jul 2011 09:09:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-8867) Unable to list root
 HA-JNDI bindings
In-Reply-To: <1614517690.17912.1297463326665.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <352346645.58465.1310821763809.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai updated JBAS-8867:
-------------------------------

           Assignee: Paul Ferraro  (was: jaikiran pai)
        Component/s: Clustering
                         (was: Other)
    Forum Reference: http://community.jboss.org/thread/162508  (was: http://community.jboss.org/thread/162508)


> Unable to list root HA-JNDI bindings 
> -------------------------------------
>
>                 Key: JBAS-8867
>                 URL: https://issues.jboss.org/browse/JBAS-8867
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 6.0.0.Final
>         Environment: Tested on CentOS  5.5 64bit / OpenJdk 64bit and Ubuntu 10.04 LTS 64bit / Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
>            Reporter: Luca Visconti
>            Assignee: Paul Ferraro
>              Labels: jmx-console
>             Fix For: 6.1.0
>
>
> Listing root HA-JNDI tree cause an exception.
> Either using JNDIView list method in jmx-console or an InitialContext.list("") cause a NPE ( Null keys are not supported! )  in Infinispan.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 10:10:23 2011
From: jira-events at lists.jboss.org (Aslak Knutsen (JIRA))
Date: Sat, 16 Jul 2011 10:10:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1291) UserTransaction not
 exposed in JNDI
In-Reply-To: <1777564578.55712.1310714483625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <567747154.58480.1310825423651.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Aslak Knutsen commented on AS7-1291:
------------------------------------

This works from within the TestCase itself.

{code}
@RunWith(Arquillian.class)
public class TransactionTestCase
{

  @Resource(mappedName = "java:/module/UserTransaction")
  private UserTransaction trans;
  ...
}
{code}

> UserTransaction not exposed in JNDI
> -----------------------------------
>
>                 Key: AS7-1291
>                 URL: https://issues.jboss.org/browse/AS7-1291
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 7.0.0.Final
>         Environment: 7.1.0.Alpha1 Jenkins build 1402
>            Reporter: Juergen Zimmermann
>            Assignee: Andrew Rubinger
>
> In JBoss 6 UserTransaction was exposed in JNDI named as java:comp/UserTransaction. Thus an Arquillian test method could be encapsulated in one single transaction:
> * lookup() the UserTransaction
> * begin() inside @Before
> * commit() inside @After
> Unfortunately, JBoss 7 doesn't have a JNDI entry for UserTransaction.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 12:11:24 2011
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Sat, 16 Jul 2011 12:11:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3143) Knowledge Agent
 does not handle multiple packages in Builder output from single resource
In-Reply-To: <1469969996.55952.1310723183785.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <927449074.58534.1310832684210.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara commented on JBRULES-3143:
-----------------------------------------

I have had the same problem recently, when building a complex KB from many knowledge resources.
I'm already working on a (simplified, actually) version of the KA which solves this problem. I will commit for review soon.

> Knowledge Agent does not handle multiple packages in Builder output from single resource
> ----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3143
>                 URL: https://issues.jboss.org/browse/JBRULES-3143
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions: 5.2.0.Final
>            Reporter: Wolfgang Laun
>            Assignee: Mark Proctor
>            Priority: Blocker
>             Fix For: 5.2.1.Final
>
>
> Note: see also https://issues.jboss.org/browse/JBRULES-2940
> KnowledgeAgent with a ChecngeSet containing a single DRL:
>    package x
>    import y.Type
>    declare Type
>       @role(event)
>    end
>    //...rules etc.
> If this is passed to the builder, it'll return two KnowledgePackageImpl objects, one with name 'x' and another one with name 'y'. But the KA only takes the first package from the Collection of packages returned by the builder.
> =!=> KA must process all packages from the builder.
> =!=> Incremental kBase building requires diff-ing between old/new packages. This, then, must take into account that contribution to one package can come from several resource builds.
> =!=> The idea that the kBuilder should return packages with different names from a single DRL build is probably wrong. If a Drools package foo contains an import bar.Type, then this is still an asset in package foo and needs to be handled as a type reference in foo. Any annotation additions must be carried by that asset foo. (The *Java* package of the imported bar.Type remains of course bar.)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 14:06:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 16 Jul 2011 14:06:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-9416) EJB3 SFSB
 performace problem: parallel calls are sequenced
In-Reply-To: <1327573270.53690.1310651003625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <170273811.58557.1310839583768.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on JBAS-9416:
------------------------------------

That's required by spec. Session beans are meant to be thread safe. Here's what the EJB3.1 spec says in section 4.3.14:

{quote}
The container serializes calls to each stateful and stateless session bean instance. Most containers will
support many instances of a session bean executing concurrently; however, each instance sees only a
serialized sequence of method calls. 
....

By default, clients are allowed to make concurrent calls to a stateful session object and the container is
required to serialize such concurrent requests. Note that the container never permits multi-threaded
access to the actual stateful session bean instance.
{quote}


> EJB3 SFSB performace problem: parallel calls are sequenced
> ----------------------------------------------------------
>
>                 Key: JBAS-9416
>                 URL: https://issues.jboss.org/browse/JBAS-9416
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Radim Hanus
>         Attachments: jboss-5.1_server.log, jboss-6.0_server.log, sfsbtest.zip, thread_dump.txt
>
>
> When a client looks up more SFSB of given type in dedicated threads and subsequently calls business methods then such calls are always sequenced.
> Works fine in jboss-5.1.0

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 14:06:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 16 Jul 2011 14:06:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-9416) EJB3 SFSB performace
 problem: parallel calls are sequenced
In-Reply-To: <1327573270.53690.1310651003625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1082245266.58559.1310839583869.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai closed JBAS-9416.
------------------------------

    Resolution: Rejected


Not a bug. So closing.


> EJB3 SFSB performace problem: parallel calls are sequenced
> ----------------------------------------------------------
>
>                 Key: JBAS-9416
>                 URL: https://issues.jboss.org/browse/JBAS-9416
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Radim Hanus
>         Attachments: jboss-5.1_server.log, jboss-6.0_server.log, sfsbtest.zip, thread_dump.txt
>
>
> When a client looks up more SFSB of given type in dedicated threads and subsequently calls business methods then such calls are always sequenced.
> Works fine in jboss-5.1.0

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 14:08:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sat, 16 Jul 2011 14:08:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-9416) EJB3 SFSB
 performace problem: parallel calls are sequenced
In-Reply-To: <1327573270.53690.1310651003625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1472243384.58563.1310839703769.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai reopened JBAS-9416:
--------------------------------



Reopening. I might have misunderstood the issue here. Are you saying you are invoking on separate instances of SFSB?

> EJB3 SFSB performace problem: parallel calls are sequenced
> ----------------------------------------------------------
>
>                 Key: JBAS-9416
>                 URL: https://issues.jboss.org/browse/JBAS-9416
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Radim Hanus
>         Attachments: jboss-5.1_server.log, jboss-6.0_server.log, sfsbtest.zip, thread_dump.txt
>
>
> When a client looks up more SFSB of given type in dedicated threads and subsequently calls business methods then such calls are always sequenced.
> Works fine in jboss-5.1.0

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 19:11:23 2011
From: jira-events at lists.jboss.org (Richard Kennard (JIRA))
Date: Sat, 16 Jul 2011 19:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-708) Ability to specify
 classloading exceptions to ignore similar to
 scanning-deployers-jboss-beans.xml
In-Reply-To: <76119589.26581.1304391198359.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1962719755.58615.1310857883675.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Richard Kennard commented on AS7-708:
-------------------------------------

Can I humbly suggest a compromise?

It sounds like this is affecting several projects, but unfortunately it's a complex issue. It's going to take a while to 'come up with the right set of requirements'. So while we're all debating that, can we just have this hard error turned into a log (WARN, even an ERROR or SEVERE if you want) rather than stopping the whole deployment?

We can turn it back into 'stopping the whole deployment' once we're sure what the requirements are.

Richard.

> Ability to specify classloading exceptions to ignore similar to scanning-deployers-jboss-beans.xml
> --------------------------------------------------------------------------------------------------
>
>                 Key: AS7-708
>                 URL: https://issues.jboss.org/browse/AS7-708
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: Jason Porter
>            Assignee: David Lloyd
>         Attachments: catch-demo.war
>
>
> We need to be able to specify exceptions to ignore during classpath scanning. This was available in AS6, we need it in AS7, or something similar. Please see https://issues.jboss.org/browse/SEAMFORGE-156

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 19:40:23 2011
From: jira-events at lists.jboss.org (Andrew Wheeler (JIRA))
Date: Sat, 16 Jul 2011 19:40:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1304) Resource Adapter
 configuration corrupts standalone.xml
Message-ID: <926766428.58626.1310859623685.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Resource Adapter configuration corrupts standalone.xml
------------------------------------------------------

                 Key: AS7-1304
                 URL: https://issues.jboss.org/browse/AS7-1304
             Project: Application Server 7
          Issue Type: Bug
          Components: JCA
    Affects Versions: 7.0.0.Final
         Environment: Linux
            Reporter: Andrew Wheeler
            Assignee: Jesper Pedersen
            Priority: Critical


When defining a resource adapter in the standalone.xml which includes a config-property it is overwriten by the server which modifies the config-properties in a manner which prevents the server from booting on the next restart

>From standalone:
                <resource-adapter>
                    <archive>
                        jackrabbit-jca.rar
                    </archive>
                    <transaction-support>
                        XATransaction
                    </transaction-support>
                    <connection-definitions>
                        <connection-definition class-name="org.apache.jackrabbit.jca.JCAManagedConnectionFactory" jndi-name="java:/jcr/ConnectionFactory" enabled="true" use-java-context="true" pool-name="jackrabbit" use-ccm="true">
			    <config-property name="HomeDir">${jboss.server.data.dir}/jackrabbit</config-property>
			    <config-property name="ConfigFile">${jboss.server.data.dir}/jackrabbit/jackrabbit.xml</config-property>
                        </connection-definition>
                    </connection-definitions>
                </resource-adapter>

The config-property then becomes in the overwritten standalone.xml:
<config-property>(HomeDir => /opt/jboss7/standalone/data/jackrabbit)</config-property>

this causes the server to fail to parse standalone.xml and subsequently does not start on the next restart with the following error:

ERROR [stderr] Exception in thread "Controller Boot Thread" java.lang.RuntimeException: org.jboss.as.controller.persistence.ConfigurationPersistenceException: Failed to parse configuration


Also, the JCA connector is not getting the correct parameters, so the resource throws an exception:

WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri] (http--127.0.0.1-8080-6) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Failed to create session: Unable to access a repository with the following settings:
    org.apache.jackrabbit.repository.conf: ("ConfigFile" => "/opt/jboss7/standalone/data/jackrabbit/jackrabbit.xml")
    org.apache.jackrabbit.repository.home: ("HomeDir" => "/opt/jboss7/standalone/data/jackrabbit")
Perhaps the repository you are trying to access is not available at the moment.

This error is thrown by Jackrabbit as it cannot access the configuration file. I'm guessing that it has trouble parsing the string passed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 16 20:07:23 2011
From: jira-events at lists.jboss.org (Luis Conceicao (JIRA))
Date: Sat, 16 Jul 2011 20:07:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-9418) Upgrade HornetQ to
	2.2.5.Final
Message-ID: <59090345.58628.1310861243700.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Upgrade HornetQ to 2.2.5.Final
------------------------------

                 Key: JBAS-9418
                 URL: https://issues.jboss.org/browse/JBAS-9418
             Project: Legacy JBoss Application Server 6 
          Issue Type: Component  Upgrade
      Security Level: Public (Everyone can see)
          Components: JMS (HornetQ)
    Affects Versions: 6.0.0.Final
            Reporter: Luis Conceicao
            Assignee: Clebert Suconic
             Fix For: 6.1.0


Upgrade HornetQ to 2.2.5.Final

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 17 00:57:25 2011
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Sun, 17 Jul 2011 00:57:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-649) Indentation of
 multiline text content in standalone.xml keeps increasing on rewrites
In-Reply-To: <2028263512.28653.1302794853658.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <472565748.58634.1310878645003.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

SBS JIRA Integration updated AS7-649:
-------------------------------------

    Forum Reference: http://community.jboss.org/message/615645#615645


> Indentation of multiline text content in standalone.xml keeps increasing on rewrites
> ------------------------------------------------------------------------------------
>
>                 Key: AS7-649
>                 URL: https://issues.jboss.org/browse/AS7-649
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: XML Frameworks
>            Reporter: David Bosschaert
>            Priority: Minor
>
> The standalone.xml file contains some XML tags that contain multi-line XML text, e.g.:
> {code}<property name="org.jboss.osgi.system.modules">
>     org.apache.log4j,
>     org.jboss.as.osgi,
>     javax.inject.api,
>     ...{code}
> The problem is that every automatic rewrite of the standalone.xml (e.g. when you deploy a new thing) the indentation increases from the 2nd line of the text, so after the first rewrite it looks like this:
> {code}<property name="org.jboss.osgi.system.modules">
>     org.apache.log4j,
>             org.jboss.as.osgi,
>             javax.inject.api,
>     ...{code}
> after a few deploys it ends up looking like this:
> {code}<property name="org.jboss.osgi.system.modules">
>     org.apache.log4j,
>                                                                                             org.jboss.as.osgi,
>                                                                                             javax.inject.api,
>     ...{code}
> Pretty ugly :(
> Would be nice if the indentation could be left untouched.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 17 03:59:23 2011
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Sun, 17 Jul 2011 03:59:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3144) Experiment with
 "when rule becomes true execute a callback" feature in Drools Expert,
 benchmarked by Drools Planner
Message-ID: <1793604597.58674.1310889563605.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Experiment with "when rule becomes true execute a callback" feature in Drools Expert, benchmarked by Drools Planner
-------------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-3144
                 URL: https://issues.jboss.org/browse/JBRULES-3144
             Project: Drools
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: drools-core  (expert), drools-planner
            Reporter: Geoffrey De Smet
            Assignee: Geoffrey De Smet


<_conan_> ge0ffrey: can do unfalse situation
<ge0ffrey> conan: is there a way to get a "when the rule no longer applies, execture this code"?
<_conan_> ge0ffrey: i.e. when a ruel becomes untrue execute a callback
<ge0ffrey> conan: yes!
<_conan_> yes
<_conan_> it's trivial to do actually
<ge0ffrey> conan: what's the code name for that feature?
<_conan_> not related to TMS
<ge0ffrey> yep
<_conan_> you can potentially hack one for yourself
<_conan_> in about 10 minutes
<ge0ffrey> I 'd also need to have a value which was caclulated in hte the orginal RHS
<_conan_> but the feature over all will take a lot of thought, due to language design
<_conan_> but for your use case
<_conan_> it's trivial to do
<_conan_> in the rule you have the Activation
<_conan_> the impl is the AgendaItem
<ge0ffrey> conan: would love to do this (espeically if I get some appointed time for it :)
<_conan_> you can do kcontext.getActivation
<_conan_> it'll take you 15 minutes to do it
<_conan_> change AgendaItem to have new field reference Callable or what ever you want to use.
<ge0ffrey> k
<_conan_> in the consequnce just do agendaItem.addCallable( new Callable() {............ } );
<_conan_> i.e. use an anonymous class
<_conan_> the only thing you need to do now
<_conan_> is in RuleTerminalNode in retractLeftTuple is agendaItem.executeCallables()
<_conan_> that's it
<_conan_> it's that trivial
<ge0ffrey> (copy pasting htis in an issue to look at later, as my workspace is open on my fork today)
<_conan_> I just don't want to expose that as a generic feature
<_conan_> because the issue needs more thought
<ge0ffrey> of course
<_conan_> with regards to language design
<_conan_> but for your use case
<_conan_> and as you are an expert
<_conan_> it's fine
<_conan_> I'd suggest you just maintain a "patched" version of drools for that feature
<ge0ffrey> but if the exeperiment works well, we can look at language design
<_conan_> yes
<_conan_> I need this anyway
<_conan_> becausae rule engines need to tell peopl when things stop being true
<ge0ffrey> conan: not going to start using for released planner until it's in drools expert for real

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 17 04:42:23 2011
From: jira-events at lists.jboss.org (Emanuele Mariani (JIRA))
Date: Sun, 17 Jul 2011 04:42:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3123) [Regression]
 .rf file raises a null pointer exception when it is loaded
In-Reply-To: <1509811794.41878.1310129063858.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1311775853.58687.1310892143828.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Emanuele Mariani commented on JBRULES-3123:
-------------------------------------------

Hi,
I had the same problem and with debug I discover that the new approch to create a ProcessBuilder is to use a "org.jbpm.process.builder.ProcessBuilderFactoryServiceImpl" (row 26 of ProcessBuilderFactory).

Searching on all the parents pom.xml of knoledge-api I see that drools project is composed by drools api and jbpm api and if i tried to include this dependency:
   <groupId>org.jbpm</groupId>
   <artifactId>jbpm-bpmn2</artifactId>
   <version>5.1.0.Final</version>
With this inclusion the ProcessBuilderFactory find the ProcessBuilderFactoryServiceImpl on the classpath and all work correctly.

So, I suppose that is only a problem of not proper dependency management.

I hope I helped
Bye 

> [Regression] .rf file raises a null pointer exception when it is loaded
> -----------------------------------------------------------------------
>
>                 Key: JBRULES-3123
>                 URL: https://issues.jboss.org/browse/JBRULES-3123
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.2.0.Final
>            Reporter: Quentin Caillard
>            Assignee: Mark Proctor
>         Attachments: jUnitTest.tar.gz, jUnitTest.tar.gz
>
>
> I have just switched from version 5.1.1 to 5.2.0.Final
> I have a ruleflow (.rf) file which can be loaded. I have the following stack trace :
> java.lang.NullPointerException
> 	at org.drools.compiler.PackageBuilder.addProcessFromXml(PackageBuilder.java:516)
> 	at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:556)
> 	at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:28)
> 	at com.ariadnext.NewDroolsTest$RulesUtils.loadRules(NewDroolsTest.java:107)
> I made a simple junit test which reproduces the bug.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 17 04:47:23 2011
From: jira-events at lists.jboss.org (Emanuele Mariani (JIRA))
Date: Sun, 17 Jul 2011 04:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (JBRULES-3123)
 [Regression] .rf file raises a null pointer exception when it is loaded
In-Reply-To: <1509811794.41878.1310129063858.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1988318260.58691.1310892443727.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Emanuele Mariani edited comment on JBRULES-3123 at 7/17/11 4:46 AM:
--------------------------------------------------------------------

Hi,
I had the same problem and with debug I discover that the new approch to create a ProcessBuilder is to use a "org.jbpm.process.builder.ProcessBuilderFactoryServiceImpl" (row 26 of ProcessBuilderFactory).

Searching on all the parents pom.xml of knoledge-api I see that drools project is composed by drools api and jbpm api and if i tried to include this dependency:
   <groupId>org.jbpm</groupId>
   <artifactId>jbpm-bpmn2</artifactId>
   <version>5.1.0.Final</version>
With this inclusion the ProcessBuilderFactory find the ProcessBuilderFactoryServiceImpl on the classpath and all work correctly.

So, I suppose that is only a problem of not proper dependency management.

I hope I helped you
Bye 

      was (Author: marlele):
    Hi,
I had the same problem and with debug I discover that the new approch to create a ProcessBuilder is to use a "org.jbpm.process.builder.ProcessBuilderFactoryServiceImpl" (row 26 of ProcessBuilderFactory).

Searching on all the parents pom.xml of knoledge-api I see that drools project is composed by drools api and jbpm api and if i tried to include this dependency:
   <groupId>org.jbpm</groupId>
   <artifactId>jbpm-bpmn2</artifactId>
   <version>5.1.0.Final</version>
With this inclusion the ProcessBuilderFactory find the ProcessBuilderFactoryServiceImpl on the classpath and all work correctly.

So, I suppose that is only a problem of not proper dependency management.

I hope I helped
Bye 
  
> [Regression] .rf file raises a null pointer exception when it is loaded
> -----------------------------------------------------------------------
>
>                 Key: JBRULES-3123
>                 URL: https://issues.jboss.org/browse/JBRULES-3123
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.2.0.Final
>            Reporter: Quentin Caillard
>            Assignee: Mark Proctor
>         Attachments: jUnitTest.tar.gz, jUnitTest.tar.gz
>
>
> I have just switched from version 5.1.1 to 5.2.0.Final
> I have a ruleflow (.rf) file which can be loaded. I have the following stack trace :
> java.lang.NullPointerException
> 	at org.drools.compiler.PackageBuilder.addProcessFromXml(PackageBuilder.java:516)
> 	at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:556)
> 	at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:28)
> 	at com.ariadnext.NewDroolsTest$RulesUtils.loadRules(NewDroolsTest.java:107)
> I made a simple junit test which reproduces the bug.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 17 07:35:23 2011
From: jira-events at lists.jboss.org (maas vdberg (JIRA))
Date: Sun, 17 Jul 2011 07:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1305) delete-snapshot
 autocomplete does not suggest name parameter
Message-ID: <819630759.58698.1310902523633.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

delete-snapshot autocomplete does not suggest name parameter
------------------------------------------------------------

                 Key: AS7-1305
                 URL: https://issues.jboss.org/browse/AS7-1305
             Project: Application Server 7
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 7.0.0.Final
            Reporter: maas vdberg
            Assignee: Brian Stansberry
            Priority: Minor




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 17 09:43:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Sun, 17 Jul 2011 09:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1304) Resource Adapter
 configuration corrupts standalone.xml
In-Reply-To: <926766428.58626.1310859623685.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <127575105.58712.1310910203753.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen reassigned AS7-1304:
------------------------------------

    Assignee: Stefano Maestri  (was: Jesper Pedersen)


> Resource Adapter configuration corrupts standalone.xml
> ------------------------------------------------------
>
>                 Key: AS7-1304
>                 URL: https://issues.jboss.org/browse/AS7-1304
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 7.0.0.Final
>         Environment: Linux
>            Reporter: Andrew Wheeler
>            Assignee: Stefano Maestri
>            Priority: Critical
>
> When defining a resource adapter in the standalone.xml which includes a config-property it is overwriten by the server which modifies the config-properties in a manner which prevents the server from booting on the next restart
> From standalone:
>                 <resource-adapter>
>                     <archive>
>                         jackrabbit-jca.rar
>                     </archive>
>                     <transaction-support>
>                         XATransaction
>                     </transaction-support>
>                     <connection-definitions>
>                         <connection-definition class-name="org.apache.jackrabbit.jca.JCAManagedConnectionFactory" jndi-name="java:/jcr/ConnectionFactory" enabled="true" use-java-context="true" pool-name="jackrabbit" use-ccm="true">
> 			    <config-property name="HomeDir">${jboss.server.data.dir}/jackrabbit</config-property>
> 			    <config-property name="ConfigFile">${jboss.server.data.dir}/jackrabbit/jackrabbit.xml</config-property>
>                         </connection-definition>
>                     </connection-definitions>
>                 </resource-adapter>
> The config-property then becomes in the overwritten standalone.xml:
> <config-property>(HomeDir => /opt/jboss7/standalone/data/jackrabbit)</config-property>
> this causes the server to fail to parse standalone.xml and subsequently does not start on the next restart with the following error:
> ERROR [stderr] Exception in thread "Controller Boot Thread" java.lang.RuntimeException: org.jboss.as.controller.persistence.ConfigurationPersistenceException: Failed to parse configuration
> Also, the JCA connector is not getting the correct parameters, so the resource throws an exception:
> WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri] (http--127.0.0.1-8080-6) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Failed to create session: Unable to access a repository with the following settings:
>     org.apache.jackrabbit.repository.conf: ("ConfigFile" => "/opt/jboss7/standalone/data/jackrabbit/jackrabbit.xml")
>     org.apache.jackrabbit.repository.home: ("HomeDir" => "/opt/jboss7/standalone/data/jackrabbit")
> Perhaps the repository you are trying to access is not available at the moment.
> This error is thrown by Jackrabbit as it cannot access the configuration file. I'm guessing that it has trouble parsing the string passed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 17 10:02:23 2011
From: jira-events at lists.jboss.org (Karel Kyovsky Kyovsky (JIRA))
Date: Sun, 17 Jul 2011 10:02:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-9416) EJB3 SFSB
 performace problem: parallel calls are sequenced
In-Reply-To: <1327573270.53690.1310651003625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <232622607.58716.1310911343695.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Karel Kyovsky Kyovsky commented on JBAS-9416:
---------------------------------------------

Yes, I can confirm that the issue is related to two separate state-full session bean instances.
We have been looking at this issue more than a week and trying almost anything.
I still don't understand why no one else didn't report this bug...

Best is to try proof of bug code-sample that Radim prepared.

> EJB3 SFSB performace problem: parallel calls are sequenced
> ----------------------------------------------------------
>
>                 Key: JBAS-9416
>                 URL: https://issues.jboss.org/browse/JBAS-9416
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Radim Hanus
>         Attachments: jboss-5.1_server.log, jboss-6.0_server.log, sfsbtest.zip, thread_dump.txt
>
>
> When a client looks up more SFSB of given type in dedicated threads and subsequently calls business methods then such calls are always sequenced.
> Works fine in jboss-5.1.0

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 17 10:56:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sun, 17 Jul 2011 10:56:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-9416) EJB3 SFSB
 performace problem: parallel calls are sequenced
In-Reply-To: <1327573270.53690.1310651003625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <831752330.58733.1310914584072.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai reassigned JBAS-9416:
----------------------------------

    Assignee: jaikiran pai


> EJB3 SFSB performace problem: parallel calls are sequenced
> ----------------------------------------------------------
>
>                 Key: JBAS-9416
>                 URL: https://issues.jboss.org/browse/JBAS-9416
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Radim Hanus
>            Assignee: jaikiran pai
>         Attachments: jboss-5.1_server.log, jboss-6.0_server.log, sfsbtest.zip, thread_dump.txt
>
>
> When a client looks up more SFSB of given type in dedicated threads and subsequently calls business methods then such calls are always sequenced.
> Works fine in jboss-5.1.0

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 17 14:20:23 2011
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Sun, 17 Jul 2011 14:20:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1284) Accessing
 localhost:8080 using JBoss Web Native causes
 java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
In-Reply-To: <2087989740.53707.1310651303687.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <859631831.58750.1310926823953.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Remy Maucherat commented on AS7-1284:
-------------------------------------

Ok, I apologize for being harsh, but native is about giving more performance and scalability, so what's the point of using it on an overpriced toy platform ?
(with a broken JDK too, as it turns out)

> Accessing localhost:8080 using JBoss Web Native causes java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1284
>                 URL: https://issues.jboss.org/browse/AS7-1284
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>         Environment: Darwin osx-en-jwegne.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) Client VM (build 20.1-b02-384, mixed mode)
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)
>            Reporter: Josef Wegner
>            Assignee: Remy Maucherat
>            Priority: Minor
>         Attachments: libtcnative-1.jnilib
>
>
> Hi,
> accessing http://localhost:8080 using JBoss Web Native 2.0.9 (self compiled for x64 and downloaded from http://www.jboss.org/jbossweb/downloads/jboss-native-2-0-9.html for i386) causes following stack trace:
> {quote}
> 15:23:18,710 ERROR [org.apache.coyote.http11.Http11AprProtocol] (http--127.0.0.1-8080-1) Error reading request, ignored: java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> 	at org.apache.tomcat.jni.Socket.setrbb(Native Method)
> 	at org.apache.coyote.http11.InternalAprInputBuffer.setSocket(InternalAprInputBuffer.java:202)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:825)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: java.lang.ClassNotFoundException: sun.nio.ch.DirectBuffer from [Module "org.jboss.as.web:main" from local module loader @39e87719 (roots: /Users/jwegne/Tools/jboss-as-web-7.0.0.Final/modules)]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
> 	... 6 more
> {quote}
> This happens with only when using JDK 1.6 provided by Apple. OpenJDK 1.7 (self-compiled) works, though.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 17 18:51:23 2011
From: jira-events at lists.jboss.org (Josef Wegner (JIRA))
Date: Sun, 17 Jul 2011 18:51:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1284) Accessing
 localhost:8080 using JBoss Web Native causes
 java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
In-Reply-To: <2087989740.53707.1310651303687.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <992101498.58818.1310943083884.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Josef Wegner commented on AS7-1284:
-----------------------------------

No problem, we want to have the dev environments as similar to the production environment as possible. We use Linux, Java 64bit Java, Jboss Web native, AJP and Apache on PRD, so I try to use the same (everything but Linux).

> Accessing localhost:8080 using JBoss Web Native causes java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1284
>                 URL: https://issues.jboss.org/browse/AS7-1284
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>         Environment: Darwin osx-en-jwegne.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) Client VM (build 20.1-b02-384, mixed mode)
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)
>            Reporter: Josef Wegner
>            Assignee: Remy Maucherat
>            Priority: Minor
>         Attachments: libtcnative-1.jnilib
>
>
> Hi,
> accessing http://localhost:8080 using JBoss Web Native 2.0.9 (self compiled for x64 and downloaded from http://www.jboss.org/jbossweb/downloads/jboss-native-2-0-9.html for i386) causes following stack trace:
> {quote}
> 15:23:18,710 ERROR [org.apache.coyote.http11.Http11AprProtocol] (http--127.0.0.1-8080-1) Error reading request, ignored: java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> 	at org.apache.tomcat.jni.Socket.setrbb(Native Method)
> 	at org.apache.coyote.http11.InternalAprInputBuffer.setSocket(InternalAprInputBuffer.java:202)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:825)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: java.lang.ClassNotFoundException: sun.nio.ch.DirectBuffer from [Module "org.jboss.as.web:main" from local module loader @39e87719 (roots: /Users/jwegne/Tools/jboss-as-web-7.0.0.Final/modules)]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
> 	... 6 more
> {quote}
> This happens with only when using JDK 1.6 provided by Apple. OpenJDK 1.7 (self-compiled) works, though.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 17 21:19:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Sun, 17 Jul 2011 21:19:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1306)
 PersistenceProviderResolver.getPersistenceProviders should return new
 instances of persistence provider
Message-ID: <456326499.59056.1310951963661.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

PersistenceProviderResolver.getPersistenceProviders should return new instances of persistence provider
-------------------------------------------------------------------------------------------------------

                 Key: AS7-1306
                 URL: https://issues.jboss.org/browse/AS7-1306
             Project: Application Server 7
          Issue Type: Bug
          Components: JPA / Hibernate
    Affects Versions: 7.0.0.Final
            Reporter: Scott Marlow
            Assignee: Scott Marlow
             Fix For: 7.1.0.Alpha1


JPA specification section 9.3 states:

{code}
The results of calling the PersistenceProviderResolverHolder.getPersistencePro-
viderResolver and the PersistenceProviderResolver.getPersistenceProvid-
ers methods must not be cached.
{code}



--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 17 21:19:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Sun, 17 Jul 2011 21:19:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1306)
 PersistenceProviderResolver.getPersistenceProviders should return new
 instances of persistence provider
In-Reply-To: <456326499.59056.1310951963661.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <778211529.59058.1310951963710.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow reassigned AS7-1306:
---------------------------------

    Assignee:     (was: Scott Marlow)


> PersistenceProviderResolver.getPersistenceProviders should return new instances of persistence provider
> -------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1306
>                 URL: https://issues.jboss.org/browse/AS7-1306
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Final
>            Reporter: Scott Marlow
>             Fix For: 7.1.0.Alpha1
>
>
> JPA specification section 9.3 states:
> {code}
> The results of calling the PersistenceProviderResolverHolder.getPersistencePro-
> viderResolver and the PersistenceProviderResolver.getPersistenceProvid-
> ers methods must not be cached.
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 17 22:13:23 2011
From: jira-events at lists.jboss.org (Hanai Shisei (JIRA))
Date: Sun, 17 Jul 2011 22:13:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1307) Server does not start
 unless CONSOLE handler is specified in logging.properties.
Message-ID: <1586608485.59105.1310955203644.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Server does not start unless CONSOLE handler is specified in logging.properties.
--------------------------------------------------------------------------------

                 Key: AS7-1307
                 URL: https://issues.jboss.org/browse/AS7-1307
             Project: Application Server 7
          Issue Type: Bug
          Components: Logging
    Affects Versions: 7.0.0.Final
         Environment: Ubuntu 10.04 AMD64
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
            Reporter: Hanai Shisei
            Assignee: David Lloyd


If I change the logging configuration (standalone/configuration/logging.properties) as the following to prevent console logging:

#logger.handlers=FILE,CONSOLE
logger.handlers=FILE

Server does not start. The log file (standalone/log/boot.log) seems broken and sometimes OutOfMemoryError is recorded:


10:42:26,615 INFO  [stdout] ]): java.lang.OutOfMemoryError: Java heap space
10:42:26,615 INFO  [stdout] 	at java.util.Arrays.copyOf(Arrays.java:2882) [:1.6.0_20]
10:42:26,615 INFO  [stdout] 	at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100) [:1.6.0_20]
10:42:26,615 INFO  [stdout] 	at java.lang.StringBuilder.append(StringBuilder.java:130) [:1.6.0_20]
10:42:26,615 INFO  [stdout] 	at java.lang.StringBuilder.append(StringBuilder.java:171) [:1.6.0_20]
10:42:26,615 INFO  [stdout] 	at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:157) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
10:42:26,615 INFO  [stdout] 	at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:64) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:283) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:291) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.Logger.logRaw(Logger.java:649) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.Logger.log(Logger.java:434) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
10:42:26,616 INFO  [stdout] 	at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)
10:42:26,616 INFO  [stdout] 	at org.jboss.stdio.WriterOutputStream.finish(WriterOutputStream.java:137)
10:42:26,616 INFO  [stdout] 	at org.jboss.stdio.WriterOutputStream.write(WriterOutputStream.java:106)
10:42:26,616 INFO  [stdout] 	at java.io.PrintStream.write(PrintStream.java:430) [:1.6.0_20]
10:42:26,616 INFO  [stdout] 	at org.jboss.stdio.StdioContext$DelegatingPrintStream.write(StdioContext.java:225)
10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.handlers.UncloseableOutputStream.write(UncloseableOutputStream.java:47) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
10:42:26,616 INFO  [stdout] 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202) [:1.6.0_20]
10:42:26,616 INFO  [stdout] 	at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:263) [:1.6.0_20]
10:42:26,616 INFO  [stdout] 	at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:106) [:1.6.0_20]
10:42:26,616 INFO  [stdout] 	at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:116) [:1.6.0_20]
10:42:26,616 INFO  [stdout] 	at java.io.OutputStreamWriter.write(OutputStreamWriter.java:203) [:1.6.0_20]
10:42:26,616 INFO  [stdout] 	at java.io.Writer.write(Writer.java:140) [:1.6.0_20]
10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:68) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:64) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:283) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:291) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.Logger.logRaw(Logger.java:649) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.Logger.log(Logger.java:434) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
10:42:26,616 INFO  [stdout] 	at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 17 23:21:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sun, 17 Jul 2011 23:21:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1247) Messaging
 Configuration not support all setings defined in jboss-messaging.xsd schema
 file.
In-Reply-To: <38984762.44637.1310371103789.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2088149212.59210.1310959283811.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned AS7-1247:
-------------------------------------

    Assignee: Brian Stansberry  (was: Andy Taylor)


> Messaging Configuration not support all setings defined in jboss-messaging.xsd schema file.
> -------------------------------------------------------------------------------------------
>
>                 Key: AS7-1247
>                 URL: https://issues.jboss.org/browse/AS7-1247
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 7.0.0.CR1
>         Environment: Windows 7 x64
> Java 1.6.25 x64
> JBoss 7.0.0 CR1 - standalone-preview
>            Reporter: Tomaz Zupan
>            Assignee: Brian Stansberry
>              Labels: as7, configuration, jboss, messaging
>         Attachments: standalone-preview.xml
>
>
> Only settings included in standalone-preview.xml configuration file are supported. If some other settings from jboss-messaging.xsd schema file are included,  org.jboss.as.controller.persistence.ConfigurationPersistenceException exception is thrown while the JBoss server is starting.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 00:47:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 18 Jul 2011 00:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1297) Weld claims to be
 able to inject Principal,
 but throws RuntimeException("not implemented") at runtime
In-Reply-To: <657543885.56986.1310742867765.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <425929684.59272.1310964443705.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved AS7-1297.
---------------------------------

    Fix Version/s: 7.0.1.Final
       Resolution: Done


> Weld claims to be able to inject Principal, but throws RuntimeException("not implemented") at runtime
> -----------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1297
>                 URL: https://issues.jboss.org/browse/AS7-1297
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CDI / Weld, Security
>    Affects Versions: 7.0.0.Final, 7.1.0.Alpha1
>         Environment: Windows 7 x64, JDK 6 and 7 both tested. JBoss AS 7.0.0 release, and Jboss AS 7.1.0.Alpha1 nightly build 2011-07-15.
>            Reporter: Craig Ringer
>            Assignee: Stuart Douglas
>             Fix For: 7.0.1.Final
>
>         Attachments: jbossas7-principal-injection.zip
>
>
> In JBoss AS 7, Weld claims to be able to inject instances of  java.security.Principal. CDI archives that try to inject it do not fail at deployment time with unsatisfied dependencies. Instead, they fail later, at runtime, when injection is attempted. At this point a runtime exception indicating that principal injection isn't supported is thrown.
> This prevents user code, or external frameworks like Seam 3 Security, from providing their own producers for javax.security.Principal without requiring a qualifier to be used. 
> If JBoss AS 7's weld integration doesn't support container managed security yet (perhaps because container managed security is  not supported in JBoss AS 7 at all yet?) then it should not offer an injection point for the security principal.
> Backtrace when calling toString() on an injected proxy for a Principal:
> Caused by: java.lang.RuntimeException: not implemented
> 	at org.jboss.as.weld.services.bootstrap.WeldSecurityServices.getPrincipal(WeldSecurityServices.java:53)
> 	at org.jboss.weld.bean.builtin.ee.PrincipalBean$PrincipalCallable.call(PrincipalBean.java:48)
> 	at org.jboss.weld.bean.builtin.ee.PrincipalBean$PrincipalCallable.call(PrincipalBean.java:34)
> 	at org.jboss.weld.bean.builtin.CallableMethodHandler.invoke(CallableMethodHandler.java:50)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:62)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:125)
> 	at org.jboss.weld.security.Principal$1263393769$Proxy$_$$_Weld$Proxy$.toString(Principal$1263393769$Proxy$_$$_Weld$Proxy$.java)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 04:05:23 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Mon, 18 Jul 2011 04:05:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1308) :jndi-view in domain
 mode on profile returns success
Message-ID: <1339018757.59468.1310976323699.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

:jndi-view in domain mode on profile returns success
----------------------------------------------------

                 Key: AS7-1308
                 URL: https://issues.jboss.org/browse/AS7-1308
             Project: Application Server 7
          Issue Type: Bug
          Components: Naming
    Affects Versions: 7.0.0.Final
            Reporter: Heiko Rupp
            Assignee: John Bailey


Doing :jndi-view on /profile=default/subsystem=naming gives:

[domain at localhost:9999 subsystem=naming] :jndi-view
{
    "outcome" => "success",
    "result" => "Jndi view is only available in runtime mode."
}

This makes no sense, as the outcome is not a view on the JNDI-tree, but a failure description.
That operation should return failure instead.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 04:47:24 2011
From: jira-events at lists.jboss.org (Quentin Caillard (JIRA))
Date: Mon, 18 Jul 2011 04:47:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3123) [Regression]
 .rf file raises a null pointer exception when it is loaded
In-Reply-To: <1509811794.41878.1310129063858.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1185365420.59577.1310978844000.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Quentin Caillard commented on JBRULES-3123:
-------------------------------------------

I added the dependency in the pom.xml of my project and my test worked.

Then it seems to be a problem of dependency in the pom.xml of knowledge-api.


Thank you for the tips.

It would be easy to correct this.

> [Regression] .rf file raises a null pointer exception when it is loaded
> -----------------------------------------------------------------------
>
>                 Key: JBRULES-3123
>                 URL: https://issues.jboss.org/browse/JBRULES-3123
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.2.0.Final
>            Reporter: Quentin Caillard
>            Assignee: Mark Proctor
>         Attachments: jUnitTest.tar.gz, jUnitTest.tar.gz
>
>
> I have just switched from version 5.1.1 to 5.2.0.Final
> I have a ruleflow (.rf) file which can be loaded. I have the following stack trace :
> java.lang.NullPointerException
> 	at org.drools.compiler.PackageBuilder.addProcessFromXml(PackageBuilder.java:516)
> 	at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:556)
> 	at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:28)
> 	at com.ariadnext.NewDroolsTest$RulesUtils.loadRules(NewDroolsTest.java:107)
> I made a simple junit test which reproduces the bug.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 04:47:24 2011
From: jira-events at lists.jboss.org (Quentin Caillard (JIRA))
Date: Mon, 18 Jul 2011 04:47:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (JBRULES-3123)
 [Regression] .rf file raises a null pointer exception when it is loaded
In-Reply-To: <1509811794.41878.1310129063858.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <992384782.59582.1310978844154.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Quentin Caillard edited comment on JBRULES-3123 at 7/18/11 4:47 AM:
--------------------------------------------------------------------

I added the dependency in the pom.xml of my project and my test worked.

Then it seems to be a problem of dependency in the pom.xml of knowledge-api.


Thank you for the tips.

It would be easy to correct it.

      was (Author: qcaillard):
    I added the dependency in the pom.xml of my project and my test worked.

Then it seems to be a problem of dependency in the pom.xml of knowledge-api.


Thank you for the tips.

It would be easy to correct this.
  
> [Regression] .rf file raises a null pointer exception when it is loaded
> -----------------------------------------------------------------------
>
>                 Key: JBRULES-3123
>                 URL: https://issues.jboss.org/browse/JBRULES-3123
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.2.0.Final
>            Reporter: Quentin Caillard
>            Assignee: Mark Proctor
>         Attachments: jUnitTest.tar.gz, jUnitTest.tar.gz
>
>
> I have just switched from version 5.1.1 to 5.2.0.Final
> I have a ruleflow (.rf) file which can be loaded. I have the following stack trace :
> java.lang.NullPointerException
> 	at org.drools.compiler.PackageBuilder.addProcessFromXml(PackageBuilder.java:516)
> 	at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:556)
> 	at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:28)
> 	at com.ariadnext.NewDroolsTest$RulesUtils.loadRules(NewDroolsTest.java:107)
> I made a simple junit test which reproduces the bug.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 05:24:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 18 Jul 2011 05:24:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-2261) Allow
 application exceptions to be defined when using the throws clause.
In-Reply-To: <48907981.56263.1310733323687.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1732294960.59655.1310981063799.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf reassigned EJBTHREE-2261:
---------------------------------------

    Assignee: Carlo de Wolf


> Allow application exceptions to be defined when using the throws clause. 
> -------------------------------------------------------------------------
>
>                 Key: EJBTHREE-2261
>                 URL: https://issues.jboss.org/browse/EJBTHREE-2261
>             Project: EJB 3.0
>          Issue Type: Feature Request
>            Reporter: Shaun Appleton
>            Assignee: Carlo de Wolf
>
> Allow application exceptions to be defined when using the throws clause. 
> This has been incorporated as part of EJBTHREE-2134 and should be allowed for EJB3 used by EAP 5.x
> Depending on the resolution of http://java.net/jira/browse/EJB_SPEC-20 this may be a bug or rfe

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 05:26:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 18 Jul 2011 05:26:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-2261) Allow
 application exceptions to be defined when using the throws clause.
In-Reply-To: <48907981.56263.1310733323687.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1360747668.59659.1310981183732.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf updated EJBTHREE-2261:
------------------------------------

    Fix Version/s: 2.0.0-beta-2


> Allow application exceptions to be defined when using the throws clause. 
> -------------------------------------------------------------------------
>
>                 Key: EJBTHREE-2261
>                 URL: https://issues.jboss.org/browse/EJBTHREE-2261
>             Project: EJB 3.0
>          Issue Type: Feature Request
>            Reporter: Shaun Appleton
>            Assignee: Carlo de Wolf
>             Fix For: 2.0.0-beta-2
>
>
> Allow application exceptions to be defined when using the throws clause. 
> This has been incorporated as part of EJBTHREE-2134 and should be allowed for EJB3 used by EAP 5.x
> Depending on the resolution of http://java.net/jira/browse/EJB_SPEC-20 this may be a bug or rfe

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 05:44:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 18 Jul 2011 05:44:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1309) Port numbers are not
 correctly displayed in console
Message-ID: <314320226.59695.1310982263797.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Port numbers are not correctly displayed in console
---------------------------------------------------

                 Key: AS7-1309
                 URL: https://issues.jboss.org/browse/AS7-1309
             Project: Application Server 7
          Issue Type: Bug
          Components: Console
    Affects Versions: 7.0.0.Final
            Reporter: Heiko Braun
            Assignee: Heiko Braun
             Fix For: 7.0.1.Final


i.e. the multicast ports

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 05:44:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 18 Jul 2011 05:44:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1309) Port numbers are not
 correctly displayed in console
In-Reply-To: <314320226.59695.1310982263797.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1493017153.59698.1310982263911.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun resolved AS7-1309.
------------------------------

    Resolution: Done


> Port numbers are not correctly displayed in console
> ---------------------------------------------------
>
>                 Key: AS7-1309
>                 URL: https://issues.jboss.org/browse/AS7-1309
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Console
>    Affects Versions: 7.0.0.Final
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 7.0.1.Final
>
>
> i.e. the multicast ports

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 05:54:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 18 Jul 2011 05:54:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-762) Provide an operation
 to request service status report after server has been started
In-Reply-To: <1517511393.903.1305215551298.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <32575593.59713.1310982863748.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun updated AS7-762:
----------------------------

    Labels: console_prio  (was: )


> Provide an operation to request  service status report  after server has been started
> -------------------------------------------------------------------------------------
>
>                 Key: AS7-762
>                 URL: https://issues.jboss.org/browse/AS7-762
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>              Labels: console_prio
>             Fix For: 7.1.0.Beta1
>
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 05:56:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 18 Jul 2011 05:56:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-340) Expose platform
 mxbeans via the domain model
In-Reply-To: <1224713688.2245.1301949573058.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <100389842.59718.1310982983765.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun reassigned AS7-340:
-------------------------------

    Assignee: Brian Stansberry


> Expose platform mxbeans via the domain model
> --------------------------------------------
>
>                 Key: AS7-340
>                 URL: https://issues.jboss.org/browse/AS7-340
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>              Labels: console_prio
>             Fix For: 7.1.0.Alpha1
>
>
> Expose the java.lang.managment MXBeans.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 05:56:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 18 Jul 2011 05:56:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-738) Provide a JNDI View
 operation, similar to AS6
In-Reply-To: <1688147340.43381.1305040998290.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1883580716.59720.1310982983922.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun commented on AS7-738:
---------------------------------

Seems to be there already: 

[standalone at localhost:9999 /] /subsystem=naming:jndi-view

> Provide a JNDI View operation, similar to AS6
> ---------------------------------------------
>
>                 Key: AS7-738
>                 URL: https://issues.jboss.org/browse/AS7-738
>             Project: Application Server 7
>          Issue Type: Enhancement
>          Components: Domain Management, Naming
>            Reporter: Heiko Braun
>             Fix For: 7.1.0.Alpha1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 05:58:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 18 Jul 2011 05:58:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1310) Manage resource
 adapters through web console
Message-ID: <1962862106.59724.1310983103616.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Manage resource adapters through web console
--------------------------------------------

                 Key: AS7-1310
                 URL: https://issues.jboss.org/browse/AS7-1310
             Project: Application Server 7
          Issue Type: Feature Request
          Components: Console
            Reporter: Heiko Braun
            Assignee: Heiko Braun
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 06:04:23 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Mon, 18 Jul 2011 06:04:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1308) :jndi-view in
 domain mode on profile returns success
In-Reply-To: <1339018757.59468.1310976323699.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1368947703.59772.1310983463732.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Rupp commented on AS7-1308:
---------------------------------

Patch is at https://github.com/pilhuhn/jboss-as/commit/b463fc992577c23b6d6788d3bc514246cc4e6c37

> :jndi-view in domain mode on profile returns success
> ----------------------------------------------------
>
>                 Key: AS7-1308
>                 URL: https://issues.jboss.org/browse/AS7-1308
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Naming
>    Affects Versions: 7.0.0.Final
>            Reporter: Heiko Rupp
>            Assignee: John Bailey
>
> Doing :jndi-view on /profile=default/subsystem=naming gives:
> [domain at localhost:9999 subsystem=naming] :jndi-view
> {
>     "outcome" => "success",
>     "result" => "Jndi view is only available in runtime mode."
> }
> This makes no sense, as the outcome is not a view on the JNDI-tree, but a failure description.
> That operation should return failure instead.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 06:16:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 18 Jul 2011 06:16:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1311) rovide the ability to
 view sever logs through the web interface
Message-ID: <2084990845.59806.1310984183831.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

rovide the ability to view sever logs through the web interface
---------------------------------------------------------------

                 Key: AS7-1311
                 URL: https://issues.jboss.org/browse/AS7-1311
             Project: Application Server 7
          Issue Type: Feature Request
          Components: Console
            Reporter: Heiko Braun
            Assignee: Heiko Braun
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 06:30:23 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Mon, 18 Jul 2011 06:30:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-1308)
 :jndi-view in domain mode on profile returns success
In-Reply-To: <1339018757.59468.1310976323699.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <147060706.59829.1310985023676.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Rupp edited comment on AS7-1308 at 7/18/11 6:29 AM:
----------------------------------------------------------

Patch is at https://github.com/pilhuhn/jboss-as/commit/caed16ec2f3296867f1832825b6fe80c65e886e8

https://github.com/jbossas/jboss-as/pull/83

      was (Author: pilhuhn):
    Patch is at https://github.com/pilhuhn/jboss-as/commit/b463fc992577c23b6d6788d3bc514246cc4e6c37
  
> :jndi-view in domain mode on profile returns success
> ----------------------------------------------------
>
>                 Key: AS7-1308
>                 URL: https://issues.jboss.org/browse/AS7-1308
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Naming
>    Affects Versions: 7.0.0.Final
>            Reporter: Heiko Rupp
>            Assignee: John Bailey
>
> Doing :jndi-view on /profile=default/subsystem=naming gives:
> [domain at localhost:9999 subsystem=naming] :jndi-view
> {
>     "outcome" => "success",
>     "result" => "Jndi view is only available in runtime mode."
> }
> This makes no sense, as the outcome is not a view on the JNDI-tree, but a failure description.
> That operation should return failure instead.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 06:34:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 18 Jul 2011 06:34:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-913) provide management
 operation for the EJB container
In-Reply-To: <1527474149.31703.1306501741272.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <901322840.59841.1310985263893.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun commented on AS7-913:
---------------------------------

We would like to see things like:

- commit options
- pool sizes
- cache settings
- ejb timer configuration

> provide management operation for the EJB container
> --------------------------------------------------
>
>                 Key: AS7-913
>                 URL: https://issues.jboss.org/browse/AS7-913
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Domain Management, EJB
>            Reporter: Heiko Braun
>            Assignee: Carlo de Wolf
>              Labels: console_prio
>             Fix For: 7.1.0.Alpha1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 06:39:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 18 Jul 2011 06:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1311) Provide the ability
 to view sever logs through the web interface
In-Reply-To: <2084990845.59806.1310984183831.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1493025120.59844.1310985563680.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun updated AS7-1311:
-----------------------------

    Summary: Provide the ability to view sever logs through the web interface  (was: rovide the ability to view sever logs through the web interface)


> Provide the ability to view sever logs through the web interface
> ----------------------------------------------------------------
>
>                 Key: AS7-1311
>                 URL: https://issues.jboss.org/browse/AS7-1311
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Console
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 7.1.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 06:43:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 18 Jul 2011 06:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1312) Invalid class in
 deployment causes deployment to fail
Message-ID: <482113650.59851.1310985803632.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Invalid class in deployment causes deployment to fail
-----------------------------------------------------

                 Key: AS7-1312
                 URL: https://issues.jboss.org/browse/AS7-1312
             Project: Application Server 7
          Issue Type: Bug
            Reporter: Stuart Douglas


If jandex fails to process a class the whole deployment blow up. This should really just log a warning.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 06:47:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 18 Jul 2011 06:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1312) Invalid class in
 deployment causes deployment to fail
In-Reply-To: <482113650.59851.1310985803632.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <978292065.59857.1310986043770.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas reassigned AS7-1312:
-----------------------------------

    Assignee: Stuart Douglas


> Invalid class in deployment causes deployment to fail
> -----------------------------------------------------
>
>                 Key: AS7-1312
>                 URL: https://issues.jboss.org/browse/AS7-1312
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> If jandex fails to process a class the whole deployment blow up. This should really just log a warning.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 06:51:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 18 Jul 2011 06:51:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1312) Invalid class in
 deployment causes deployment to fail
In-Reply-To: <482113650.59851.1310985803632.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1026181090.59859.1310986283656.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved AS7-1312.
---------------------------------

    Fix Version/s: 7.0.1.Final
       Resolution: Done


> Invalid class in deployment causes deployment to fail
> -----------------------------------------------------
>
>                 Key: AS7-1312
>                 URL: https://issues.jboss.org/browse/AS7-1312
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 7.0.1.Final
>
>
> If jandex fails to process a class the whole deployment blow up. This should really just log a warning.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 06:53:24 2011
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 18 Jul 2011 06:53:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1166) Quit the CLI on EOF
In-Reply-To: <115625773.31875.1309517243776.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2091827515.59862.1310986404006.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Alexey Loubyansky resolved AS7-1166.
------------------------------------

    Fix Version/s: 7.0.1.Final
       Resolution: Done


It's fixed.

> Quit the CLI on EOF
> -------------------
>
>                 Key: AS7-1166
>                 URL: https://issues.jboss.org/browse/AS7-1166
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: CLI
>    Affects Versions: 7.1.0.Alpha1
>            Reporter: Marek Schmidt
>            Assignee: Alexey Loubyansky
>             Fix For: 7.0.1.Final
>
>
> jboss-admin.sh should behave more like a shell and terminate on EOF (ctrl-D)
> The current behavior is quite counter-intuitive and trying to do e.g.
> echo "deploy foo.war" | ./jboss-admin.sh --connect 
> leads the CLI into an infinite-loop generating infinite number of prompts.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 07:12:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 18 Jul 2011 07:12:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1313) <distributable> web
 applications fail to deploy with the default configuration
Message-ID: <540578067.59906.1310987543621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

<distributable> web applications fail to deploy with the default configuration
------------------------------------------------------------------------------

                 Key: AS7-1313
                 URL: https://issues.jboss.org/browse/AS7-1313
             Project: Application Server 7
          Issue Type: Bug
          Components: Web
    Affects Versions: 7.0.0.Final
            Reporter: Stuart Douglas
            Assignee: Remy Maucherat


<distributable> web applications fail with the following:

"Services with missing/unavailable dependencies" => ["jboss.web.\"magnolia-bundled-webapp-4.4.4.war\" missing [ jboss.infinispan.web.___defaultcache ]"]}}}

At the very least the user should get a better error message explaining why their deployment failed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 07:21:36 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 18 Jul 2011 07:21:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1314)
 LifecycleAnnotationParsingProcessor creates EEClassDescriptions for every
 class, not just component classes
Message-ID: <1361011650.59918.1310988096006.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

LifecycleAnnotationParsingProcessor creates EEClassDescriptions for every class, not just component classes 
------------------------------------------------------------------------------------------------------------

                 Key: AS7-1314
                 URL: https://issues.jboss.org/browse/AS7-1314
             Project: Application Server 7
          Issue Type: Bug
          Components: EE
    Affects Versions: 7.0.0.Final
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas
             Fix For: 7.0.1.Final




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 07:23:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 18 Jul 2011 07:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-913) provide management
 operation for the EJB container
In-Reply-To: <1527474149.31703.1306501741272.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1182528341.59936.1310988203641.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf commented on AS7-913:
-----------------------------------

- security settings

> provide management operation for the EJB container
> --------------------------------------------------
>
>                 Key: AS7-913
>                 URL: https://issues.jboss.org/browse/AS7-913
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Domain Management, EJB
>            Reporter: Heiko Braun
>            Assignee: Carlo de Wolf
>              Labels: console_prio
>             Fix For: 7.1.0.Alpha1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 07:30:23 2011
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 18 Jul 2011 07:30:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1314)
 LifecycleAnnotationParsingProcessor creates EEClassDescriptions for every
 class, not just component classes
In-Reply-To: <1361011650.59918.1310988096006.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <120602411.59957.1310988623701.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Geoffrey De Smet commented on AS7-1314:
---------------------------------------

according to stuart, this causes this issue when deploying seam-international 3.0.0.Final to AS7:

{code}
12:03:28,569 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.deployment.unit."guvnor-webapp-5.3.0-SNAPSHOT.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."guvnor-webapp-5.3.0-SNAPSHOT.war".INSTALL: Failed to process phase INSTALL of deployment "guvnor-webapp-5.3.0-SNAPSHOT.war"
        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
        at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
        at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
Caused by: java.lang.RuntimeException: Error getting reflective information for class org.jboss.seam.international.datetimezone.DefaultDateTimeZoneProducer
        at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:70)
        at org.jboss.as.ee.component.EEModuleClassDescription$DefaultConfigurator.configure(EEModuleClassDescription.java:144)
        at org.jboss.as.ee.component.EEClassConfigurationProcessor.deploy(EEClassConfigurationProcessor.java:100)
        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
        ... 5 more
Caused by: java.lang.NoClassDefFoundError: org/joda/time/DateTimeZone
        at java.lang.Class.getDeclaredFields0(Native Method) [:1.6.0_24]
        at java.lang.Class.privateGetDeclaredFields(Class.java:2291) [:1.6.0_24]
        at java.lang.Class.getDeclaredFields(Class.java:1743) [:1.6.0_24]
        at org.jboss.as.server.deployment.reflect.ClassReflectionIndex.<init>(ClassReflectionIndex.java:57)
        at org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:66)
        ... 8 more
Caused by: java.lang.ClassNotFoundException: org.joda.time.DateTimeZone from [Module "deployment.guvnor-webapp-5.3.0-SNAPSHOT.war:main" from Service Module Loader]
        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
        ... 13 more
{code}

> LifecycleAnnotationParsingProcessor creates EEClassDescriptions for every class, not just component classes 
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1314
>                 URL: https://issues.jboss.org/browse/AS7-1314
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 7.0.0.Final
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 7.0.1.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 07:34:24 2011
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Mon, 18 Jul 2011 07:34:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1315) Console can't show
 more than 5 system properties
Message-ID: <329919954.59996.1310988864407.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Console can't show more than 5 system properties
------------------------------------------------

                 Key: AS7-1315
                 URL: https://issues.jboss.org/browse/AS7-1315
             Project: Application Server 7
          Issue Type: Bug
          Components: Console
    Affects Versions: 7.0.0.Final
            Reporter: Stan Silvert
            Assignee: Heiko Braun


The console will only show the first 5 system properties.  Using the console, you can still add additional properties to standalone.xml, but they won't be displayed.

Reported by a user in this thread: http://community.jboss.org/message/615618#615618

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 07:36:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 18 Jul 2011 07:36:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-913) provide management
 operation for the EJB container
In-Reply-To: <1527474149.31703.1306501741272.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <100965236.60002.1310988983713.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf updated AS7-913:
------------------------------

    Fix Version/s: 7.1.0.CR1
                       (was: 7.1.0.Alpha1)


> provide management operation for the EJB container
> --------------------------------------------------
>
>                 Key: AS7-913
>                 URL: https://issues.jboss.org/browse/AS7-913
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Domain Management, EJB
>            Reporter: Heiko Braun
>            Assignee: Carlo de Wolf
>              Labels: console_prio
>             Fix For: 7.1.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 07:36:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 18 Jul 2011 07:36:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1315) Console can't show
 more than 5 system properties
In-Reply-To: <329919954.59996.1310988864407.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <825278930.60006.1310988983850.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun updated AS7-1315:
-----------------------------

      Fix Version/s: 7.0.1.Final
    Forum Reference: http://community.jboss.org/message/615618#615618  (was: http://community.jboss.org/message/615618#615618)


> Console can't show more than 5 system properties
> ------------------------------------------------
>
>                 Key: AS7-1315
>                 URL: https://issues.jboss.org/browse/AS7-1315
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Console
>    Affects Versions: 7.0.0.Final
>            Reporter: Stan Silvert
>            Assignee: Heiko Braun
>             Fix For: 7.0.1.Final
>
>
> The console will only show the first 5 system properties.  Using the console, you can still add additional properties to standalone.xml, but they won't be displayed.
> Reported by a user in this thread: http://community.jboss.org/message/615618#615618

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 07:38:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 18 Jul 2011 07:38:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1281) Cannot deploy
 different EARs with same WARs inside.
In-Reply-To: <1792558469.53067.1310634804225.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <757054853.60014.1310989103678.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf updated AS7-1281:
-------------------------------

           Assignee: Remy Maucherat  (was: Carlo de Wolf)
        Component/s: Web
                         (was: EJB)
    Forum Reference: http://community.jboss.org/message/615120#615120, http://community.jboss.org/thread/169402?tstart=0  (was: http://community.jboss.org/message/615120#615120, http://community.jboss.org/thread/169402?tstart=0)


> Cannot deploy different EARs with same WARs inside.
> ---------------------------------------------------
>
>                 Key: AS7-1281
>                 URL: https://issues.jboss.org/browse/AS7-1281
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>         Environment: $uname -a
> Linux 2.6.38-10-generic-pae #46-Ubuntu SMP Tue Jun 28 16:54:49 UTC 2011 i686 i686 i386 GNU/Linux
>            Reporter: Juri Timo?in
>            Assignee: Remy Maucherat
>              Labels: deploy, duplicate-service-exception, ear, ejb, war
>
> Hello, I have a problem of deploying several EARs on jboss-as-7.0.0-Final.
>  
> I have 2 EARs, both have test.war inside them. I cannot deploy both EARs at the same time
>  
> 10:09:31,237 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.subunit."myTest.ear"."test.war".INSTALL: org.jboss.msc.
> service.StartException in service jboss.deployment.subunit."myTest.ear"."test.war".INSTALL: Failed to process phase INSTALL of subdeployment "test.war" of deployment "myTest.ear"
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
>         at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
>         at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to add JBoss web deployment service
>         at org.jboss.as.web.deployment.WarDeploymentProcessor.processDeployment(WarDeploymentProcessor.java:234)
>         at org.jboss.as.web.deployment.WarDeploymentProcessor.deploy(WarDeploymentProcessor.java:105)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
>         ... 5 more
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.web.realm."test.war" is already registered
>         at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:154)
>         at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:226)
>         at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:560)
>         at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201)
>         at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2194)
>         at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201)
>         at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2194)
>         at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:307)
>         at org.jboss.as.web.deployment.WarDeploymentProcessor.processDeployment(WarDeploymentProcessor.java:209)
>         ... 7 more
>  
> If I deploy them 1 by 1 then only the first one deploys. If i deploy them both at the same time, then both deployments are rolled back.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul 18 07:44:23 2011
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Mon, 18 Jul 2011 07:44:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1281) Cannot deploy
 different EARs with same WARs inside.
In-Reply-To: <1792558469.53067.1310634804225.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <825994039.60024.1310989463636.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Remy Maucherat commented on AS7-1281:
-------------------------------------

Ok, that might not be the best service name then :D

> Cannot deploy different EARs with same WARs inside.
> ---------------------------------------------------
>
>                 Key: AS7-1281
>                 URL: https://issues.jboss.org/browse/AS7-1281
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>         Environment: $uname -a
> Linux 2.6.38-10-generic-pae #46-Ubuntu SMP Tue Jun 28 16:54:49 UTC 2011 i686 i686 i386 GNU/Linux
>            Reporter: Juri Timo?in
>            Assignee: Remy Maucherat
>              Labels: deploy, duplicate-service-exception, ear, ejb, war
>
> Hello, I have a problem of deploying several EARs on jboss-as-7.0.0-Final.
>  
> I have 2 EARs, both have test.war inside them. I cannot deploy both EARs at the same time
>  
> 10:09:31,237 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.subunit."myTest.ear"."test.war".INSTALL: org.jboss.msc.
> service.StartException in service jboss.deployment.subunit."myTest.ear"."test.war".INSTALL: Failed to process phase INSTALL of subdeployment "test.war" of deployment "myTest.ear"
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
>         at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
>         at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to add JBoss web deployment service
>         at org.jboss.as.web.deployment.WarDeploymentProcessor.processDeployment(WarDeploymentProcessor.java:234)
>         at org.jboss.as.web.deployment.WarDeploymentProcessor.deploy(WarDeploymentProcessor.java:105)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
>         ... 5 more
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.web.realm."test.war" is already registered
>         at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:154)
>         at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:226)
>         at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:560)
>         at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201)
>         at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2194)
>         at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201)
>         at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2194)
>         at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:307)
>         at org.jboss.as.web.deployment.WarDeploymentProcessor.processDeployment(WarDeploymentProcessor.java:209)
>         ... 7 more
>  
> If I deploy them 1 by 1 then only the first one deploys. If i deploy them both at the same time, then both deployments are rolled back.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul 18 08:15:24 2011
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Mon, 18 Jul 2011 08:15:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1281) Cannot deploy
 different EARs with same WARs inside.
In-Reply-To: <1792558469.53067.1310634804225.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <434840310.60093.1310991324048.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Remy Maucherat commented on AS7-1281:
-------------------------------------

Actually ...

If two separate EARs declare the same paths for their WARs, it will fail, and it's normal.

The default path seems to be the war name (without the ear name), so the two mappings will conflict and the realm service name is right to conflict as well. However, it would be ok to add in the host to some service names, since that's valid - if the two wars actually go into separate vhosts. I don't think that's what you were attempting though ...

> Cannot deploy different EARs with same WARs inside.
> ---------------------------------------------------
>
>                 Key: AS7-1281
>                 URL: https://issues.jboss.org/browse/AS7-1281
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>         Environment: $uname -a
> Linux 2.6.38-10-generic-pae #46-Ubuntu SMP Tue Jun 28 16:54:49 UTC 2011 i686 i686 i386 GNU/Linux
>            Reporter: Juri Timo?in
>            Assignee: Remy Maucherat
>              Labels: deploy, duplicate-service-exception, ear, ejb, war
>
> Hello, I have a problem of deploying several EARs on jboss-as-7.0.0-Final.
>  
> I have 2 EARs, both have test.war inside them. I cannot deploy both EARs at the same time
>  
> 10:09:31,237 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.subunit."myTest.ear"."test.war".INSTALL: org.jboss.msc.
> service.StartException in service jboss.deployment.subunit."myTest.ear"."test.war".INSTALL: Failed to process phase INSTALL of subdeployment "test.war" of deployment "myTest.ear"
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
>         at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
>         at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to add JBoss web deployment service
>         at org.jboss.as.web.deployment.WarDeploymentProcessor.processDeployment(WarDeploymentProcessor.java:234)
>         at org.jboss.as.web.deployment.WarDeploymentProcessor.deploy(WarDeploymentProcessor.java:105)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
>         ... 5 more
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.web.realm."test.war" is already registered
>         at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:154)
>         at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:226)
>         at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:560)
>         at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201)
>         at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2194)
>         at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201)
>         at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2194)
>         at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:307)
>         at org.jboss.as.web.deployment.WarDeploymentProcessor.processDeployment(WarDeploymentProcessor.java:209)
>         ... 7 more
>  
> If I deploy them 1 by 1 then only the first one deploys. If i deploy them both at the same time, then both deployments are rolled back.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul 18 08:15:24 2011
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 18 Jul 2011 08:15:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-689) standalone server: If
 I shutdown the server,
 the client gets a IOException->ExecutionException->EOFException("Connection
 closed")
In-Reply-To: <357534374.16951.1303984642387.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <35632617.60098.1310991324252.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Alexey Loubyansky updated AS7-689:
----------------------------------

    Component/s:     (was: CLI)


Removed CLI from Components. The CLI actually handles it cleanly.

> standalone server: If I shutdown the server, the client gets a IOException->ExecutionException->EOFException("Connection closed")
> ---------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-689
>                 URL: https://issues.jboss.org/browse/AS7-689
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Beta3
>            Reporter: Andre Dietisheim
>
> If I shutdown the server by the following operation:
> {code}
> 	ModelNode request = new ModelNode();
> 	request.get(OP).set(SHUTDOWN);
> {code}
> the client throws a IOException because it's connection was closed. 
> The actual nesting is the following:
> IOException->ExecutionException->EOFException("Connection closed")

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 08:17:23 2011
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 18 Jul 2011 08:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1316) add output
 redirection for commands and operations
Message-ID: <694270928.60107.1310991443760.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

add output redirection for commands and operations
--------------------------------------------------

                 Key: AS7-1316
                 URL: https://issues.jboss.org/browse/AS7-1316
             Project: Application Server 7
          Issue Type: Task
          Components: CLI
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: 7.0.1.Final


e.g. operation > file.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 08:17:23 2011
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Mon, 18 Jul 2011 08:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1281) Cannot deploy
 different EARs with same WARs inside.
In-Reply-To: <1792558469.53067.1310634804225.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1224426865.60103.1310991443669.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Remy Maucherat updated AS7-1281:
--------------------------------

    Comment: was deleted

(was: Ok, that might not be the best service name then :D)


> Cannot deploy different EARs with same WARs inside.
> ---------------------------------------------------
>
>                 Key: AS7-1281
>                 URL: https://issues.jboss.org/browse/AS7-1281
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>         Environment: $uname -a
> Linux 2.6.38-10-generic-pae #46-Ubuntu SMP Tue Jun 28 16:54:49 UTC 2011 i686 i686 i386 GNU/Linux
>            Reporter: Juri Timo?in
>            Assignee: Remy Maucherat
>              Labels: deploy, duplicate-service-exception, ear, ejb, war
>
> Hello, I have a problem of deploying several EARs on jboss-as-7.0.0-Final.
>  
> I have 2 EARs, both have test.war inside them. I cannot deploy both EARs at the same time
>  
> 10:09:31,237 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.subunit."myTest.ear"."test.war".INSTALL: org.jboss.msc.
> service.StartException in service jboss.deployment.subunit."myTest.ear"."test.war".INSTALL: Failed to process phase INSTALL of subdeployment "test.war" of deployment "myTest.ear"
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
>         at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
>         at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to add JBoss web deployment service
>         at org.jboss.as.web.deployment.WarDeploymentProcessor.processDeployment(WarDeploymentProcessor.java:234)
>         at org.jboss.as.web.deployment.WarDeploymentProcessor.deploy(WarDeploymentProcessor.java:105)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
>         ... 5 more
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.web.realm."test.war" is already registered
>         at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:154)
>         at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:226)
>         at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:560)
>         at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201)
>         at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2194)
>         at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201)
>         at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2194)
>         at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:307)
>         at org.jboss.as.web.deployment.WarDeploymentProcessor.processDeployment(WarDeploymentProcessor.java:209)
>         ... 7 more
>  
> If I deploy them 1 by 1 then only the first one deploys. If i deploy them both at the same time, then both deployments are rolled back.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul 18 08:18:32 2011
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Mon, 18 Jul 2011 08:18:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1281) Cannot deploy
 different EARs with same WARs inside.
In-Reply-To: <1792558469.53067.1310634804225.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <293870558.60114.1310991512713.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Remy Maucherat commented on AS7-1281:
-------------------------------------

In WarDeploymentProcessor, I would thus append hostName to the deploymentName. Maybe something like "[hostName]" + deploymentUnit.getName() to avoid conflicts. Need to see with others though.

> Cannot deploy different EARs with same WARs inside.
> ---------------------------------------------------
>
>                 Key: AS7-1281
>                 URL: https://issues.jboss.org/browse/AS7-1281
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>         Environment: $uname -a
> Linux 2.6.38-10-generic-pae #46-Ubuntu SMP Tue Jun 28 16:54:49 UTC 2011 i686 i686 i386 GNU/Linux
>            Reporter: Juri Timo?in
>            Assignee: Remy Maucherat
>              Labels: deploy, duplicate-service-exception, ear, ejb, war
>
> Hello, I have a problem of deploying several EARs on jboss-as-7.0.0-Final.
>  
> I have 2 EARs, both have test.war inside them. I cannot deploy both EARs at the same time
>  
> 10:09:31,237 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.subunit."myTest.ear"."test.war".INSTALL: org.jboss.msc.
> service.StartException in service jboss.deployment.subunit."myTest.ear"."test.war".INSTALL: Failed to process phase INSTALL of subdeployment "test.war" of deployment "myTest.ear"
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
>         at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
>         at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to add JBoss web deployment service
>         at org.jboss.as.web.deployment.WarDeploymentProcessor.processDeployment(WarDeploymentProcessor.java:234)
>         at org.jboss.as.web.deployment.WarDeploymentProcessor.deploy(WarDeploymentProcessor.java:105)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
>         ... 5 more
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.web.realm."test.war" is already registered
>         at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:154)
>         at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:226)
>         at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:560)
>         at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201)
>         at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2194)
>         at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201)
>         at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2194)
>         at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:307)
>         at org.jboss.as.web.deployment.WarDeploymentProcessor.processDeployment(WarDeploymentProcessor.java:209)
>         ... 7 more
>  
> If I deploy them 1 by 1 then only the first one deploys. If i deploy them both at the same time, then both deployments are rolled back.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul 18 08:20:23 2011
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 18 Jul 2011 08:20:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1290) add cls/clear command
In-Reply-To: <449572388.55670.1310712803624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <105684035.60119.1310991623779.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Alexey Loubyansky resolved AS7-1290.
------------------------------------

    Resolution: Done


Done.

> add cls/clear command
> ---------------------
>
>                 Key: AS7-1290
>                 URL: https://issues.jboss.org/browse/AS7-1290
>             Project: Application Server 7
>          Issue Type: Task
>          Components: CLI
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 7.0.1.Final
>
>
> Add a command to clear the terminal.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 08:27:23 2011
From: jira-events at lists.jboss.org (Tihomir Surdilovic (JIRA))
Date: Mon, 18 Jul 2011 08:27:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-3076) Support
 declarative configuration of event listeners (process, agenda,
 working memory)
In-Reply-To: <1960549514.19671.1307724419574.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1562141224.60146.1310992043692.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Tihomir Surdilovic reassigned JBRULES-3076:
-------------------------------------------

    Assignee: Tihomir Surdilovic  (was: Mark Proctor)


> Support declarative configuration of event listeners (process, agenda, working memory) 
> ---------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3076
>                 URL: https://issues.jboss.org/browse/JBRULES-3076
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-spring
>            Reporter: Vinod Kiran Paidimarry
>            Assignee: Tihomir Surdilovic
>
> Support declarative configuration of event listeners (process, agenda, working memory) using Spring XML

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 08:44:24 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Mon, 18 Jul 2011 08:44:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1201) test for en/diable
	xa datasources
In-Reply-To: <628827184.37288.1309954883712.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <219056189.60183.1310993064262.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefano Maestri resolved AS7-1201.
----------------------------------

    Resolution: Done


> test for en/diable xa datasources
> ---------------------------------
>
>                 Key: AS7-1201
>                 URL: https://issues.jboss.org/browse/AS7-1201
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: Test Suite
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>             Fix For: 7.1.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 08:44:24 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Mon, 18 Jul 2011 08:44:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1206) test for jndi
 binding isn't unbound during remove if jndi name and data-source name are
 different
In-Reply-To: <915284666.37316.1309955363700.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1054741445.60186.1310993064331.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefano Maestri resolved AS7-1206.
----------------------------------

    Resolution: Done


> test for jndi binding isn't unbound during remove if jndi name and data-source name are different
> -------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1206
>                 URL: https://issues.jboss.org/browse/AS7-1206
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: Test Suite
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>             Fix For: 7.1.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 08:44:24 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Mon, 18 Jul 2011 08:44:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1202) test for enable
	datasource
In-Reply-To: <1282958622.37289.1309954883783.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1646894948.60189.1310993064392.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefano Maestri resolved AS7-1202.
----------------------------------

    Resolution: Done


> test for enable datasource
> --------------------------
>
>                 Key: AS7-1202
>                 URL: https://issues.jboss.org/browse/AS7-1202
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: Test Suite
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>             Fix For: 7.1.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 08:44:24 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Mon, 18 Jul 2011 08:44:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1200) test case for xa
 datasource persistence to xml
In-Reply-To: <688662445.37283.1309954644343.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2104323451.60191.1310993064435.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefano Maestri resolved AS7-1200.
----------------------------------

    Resolution: Done


> test case for xa datasource persistence to xml
> ----------------------------------------------
>
>                 Key: AS7-1200
>                 URL: https://issues.jboss.org/browse/AS7-1200
>             Project: Application Server 7
>          Issue Type: Sub-task
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>             Fix For: 7.1.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 08:46:23 2011
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Mon, 18 Jul 2011 08:46:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1281) Cannot deploy
 different EARs with same WARs inside.
In-Reply-To: <1792558469.53067.1310634804225.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <71394869.60196.1310993183966.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Remy Maucherat reassigned AS7-1281:
-----------------------------------

    Assignee: Emanuel Muckenhuber  (was: Remy Maucherat)


Ok, so after reviewing, the service names should probably be based on hostName + pathName. That's what AS 6 was using for the mbean names.

Not using the host breaks vhosting, and the .war deployment name does not have to be unique either (the path where it is mapped must be unique inside a vhost).

> Cannot deploy different EARs with same WARs inside.
> ---------------------------------------------------
>
>                 Key: AS7-1281
>                 URL: https://issues.jboss.org/browse/AS7-1281
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>         Environment: $uname -a
> Linux 2.6.38-10-generic-pae #46-Ubuntu SMP Tue Jun 28 16:54:49 UTC 2011 i686 i686 i386 GNU/Linux
>            Reporter: Juri Timo?in
>            Assignee: Emanuel Muckenhuber
>              Labels: deploy, duplicate-service-exception, ear, ejb, war
>
> Hello, I have a problem of deploying several EARs on jboss-as-7.0.0-Final.
>  
> I have 2 EARs, both have test.war inside them. I cannot deploy both EARs at the same time
>  
> 10:09:31,237 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.subunit."myTest.ear"."test.war".INSTALL: org.jboss.msc.
> service.StartException in service jboss.deployment.subunit."myTest.ear"."test.war".INSTALL: Failed to process phase INSTALL of subdeployment "test.war" of deployment "myTest.ear"
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
>         at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
>         at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to add JBoss web deployment service
>         at org.jboss.as.web.deployment.WarDeploymentProcessor.processDeployment(WarDeploymentProcessor.java:234)
>         at org.jboss.as.web.deployment.WarDeploymentProcessor.deploy(WarDeploymentProcessor.java:105)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
>         ... 5 more
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.web.realm."test.war" is already registered
>         at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:154)
>         at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:226)
>         at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:560)
>         at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201)
>         at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2194)
>         at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201)
>         at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2194)
>         at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:307)
>         at org.jboss.as.web.deployment.WarDeploymentProcessor.processDeployment(WarDeploymentProcessor.java:209)
>         ... 7 more
>  
> If I deploy them 1 by 1 then only the first one deploys. If i deploy them both at the same time, then both deployments are rolled back.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul 18 08:49:23 2011
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 18 Jul 2011 08:49:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1335) Collapse setState
 and getState callbacks
In-Reply-To: <929419138.10552.1308669683709.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1596046499.60202.1310993363817.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1335:
--------------------------------

The byte[] getState() and setState(byte[] state) callbacks have been removed from MessageListener and ReceiverAdapter. When we still use STATE_TRANSFER, the byte buffers will get converted (internally) into input- and output- streams

> Collapse setState and getState callbacks
> ----------------------------------------
>
>                 Key: JGRP-1335
>                 URL: https://issues.jboss.org/browse/JGRP-1335
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.6, 2.9, 2.10, 2.11, 2.12
>            Reporter: Vladimir Blagojevic
>            Assignee: Bela Ban
>             Fix For: 3.0
>
>
> Currently we maintain two sets of getState and setState callbacks, one for byte based transfer and the other for stream based transfer. Users had to implement both types of callbacks if the wanted to interchange STREAMING_STATE_TRANSFER and STATE_TRANSFER. If we use only stream based callbacks we can simplify client code and users can choose what type of transfer they want as a protocol option of STREAMING_STATE_TRANSFER. Finally, we could potentially drop STATE_TRANSFER all together.  
>  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 08:51:23 2011
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 18 Jul 2011 08:51:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1335) Collapse setState
 and getState callbacks
In-Reply-To: <929419138.10552.1308669683709.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <252804307.60208.1310993483796.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1335:
--------------------------------

I'll probably rename STREAMING_STATE_TRANSFER to STATE and STREAMING_STATE_TRANSFER_SOCKET to STATE_SOCK

> Collapse setState and getState callbacks
> ----------------------------------------
>
>                 Key: JGRP-1335
>                 URL: https://issues.jboss.org/browse/JGRP-1335
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.6, 2.9, 2.10, 2.11, 2.12
>            Reporter: Vladimir Blagojevic
>            Assignee: Bela Ban
>             Fix For: 3.0
>
>
> Currently we maintain two sets of getState and setState callbacks, one for byte based transfer and the other for stream based transfer. Users had to implement both types of callbacks if the wanted to interchange STREAMING_STATE_TRANSFER and STATE_TRANSFER. If we use only stream based callbacks we can simplify client code and users can choose what type of transfer they want as a protocol option of STREAMING_STATE_TRANSFER. Finally, we could potentially drop STATE_TRANSFER all together.  
>  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 08:51:23 2011
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 18 Jul 2011 08:51:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-1335) Collapse setState
 and getState callbacks
In-Reply-To: <929419138.10552.1308669683709.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <574492027.60214.1310993483922.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban resolved JGRP-1335.
----------------------------

    Resolution: Done


Done on JGRP-619

> Collapse setState and getState callbacks
> ----------------------------------------
>
>                 Key: JGRP-1335
>                 URL: https://issues.jboss.org/browse/JGRP-1335
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.6, 2.9, 2.10, 2.11, 2.12
>            Reporter: Vladimir Blagojevic
>            Assignee: Bela Ban
>             Fix For: 3.0
>
>
> Currently we maintain two sets of getState and setState callbacks, one for byte based transfer and the other for stream based transfer. Users had to implement both types of callbacks if the wanted to interchange STREAMING_STATE_TRANSFER and STATE_TRANSFER. If we use only stream based callbacks we can simplify client code and users can choose what type of transfer they want as a protocol option of STREAMING_STATE_TRANSFER. Finally, we could potentially drop STATE_TRANSFER all together.  
>  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 08:53:23 2011
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 18 Jul 2011 08:53:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-1344) Replace
 ChannelException with Exception
In-Reply-To: <1718526036.41193.1310106263625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1690972829.60224.1310993603739.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban resolved JGRP-1344.
----------------------------

    Resolution: Done


Removed ChannelClosedException, ChannelNotConnectedException and ChannelException. The only exceptions left are StateTransferException, TimeoutException and SuspectException.

> Replace ChannelException with Exception
> ---------------------------------------
>
>                 Key: JGRP-1344
>                 URL: https://issues.jboss.org/browse/JGRP-1344
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.0
>
>
> public void JChannel.connect(String cluster) throws ChannelException --> throws Exception
> This is more generic, and we can still throw ChannelClosedExceptions (needs to be listed in the javadoc)
> This way, we don't have to wrap an Exception received from state transfer (fetching state or setting state) into a StateTransferException

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 08:53:23 2011
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 18 Jul 2011 08:53:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-1339)
 STREAMING_STATE_TRANSFER: use_default_transport might lead to incorrect
 state transfer
In-Reply-To: <640941847.18691.1308902903728.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <371792039.60232.1310993603931.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1339:
--------------------------------

Added a BlockingInputStream, which is used in STREAMING_STATE_TRANSFER. The functionality of STREAMING_STATE_TRANSFER has been seperated into STREAMING_STATE_TRANSFER and STREAMING_STATE_TRANSFER_SOCKET, with a common base class of StreamingStateTransfer.
Will probably rename STREAMING_STATE_TRANSFER --> STATE and STREAMING_STATE_TRANSFER_SOCKET to STATE_SOCK.

> STREAMING_STATE_TRANSFER: use_default_transport might lead to incorrect state transfer
> --------------------------------------------------------------------------------------
>
>                 Key: JGRP-1339
>                 URL: https://issues.jboss.org/browse/JGRP-1339
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.12.2, 3.0
>
>
> If read(byte[] buf, int offset, int len) is invoked on a StateInputStream, we do the following:
> - stateQueue.take() is called to grab the next message (block if no message is available)
> - Then we return the byte[] buffer of the message. The number of bytes returned is buffer.length, *not* len !
> This has 3 issues:
> #1 It violates the contract of read(): if we wanted to read len bytes at most, we cannot get more bytes back. E.g. if we wanted to read 500 bytes, but get 1000 back, then that's incorrect
> #2 If we allocate a buffer of 500 bytes, but the next message has 1000 bytes, we will get an array out of bounds exception
> #3 Even if this was correct, if we wanted to read 500 bytes, but the next message has 1000 bytes, we'd only read 500 bytes and throw the remainder away !

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 08:55:23 2011
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 18 Jul 2011 08:55:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-1339)
 STREAMING_STATE_TRANSFER: use_default_transport might lead to incorrect
 state transfer
In-Reply-To: <640941847.18691.1308902903728.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <442022115.60237.1310993723799.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban resolved JGRP-1339.
----------------------------

    Resolution: Done


> STREAMING_STATE_TRANSFER: use_default_transport might lead to incorrect state transfer
> --------------------------------------------------------------------------------------
>
>                 Key: JGRP-1339
>                 URL: https://issues.jboss.org/browse/JGRP-1339
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.12.2, 3.0
>
>
> If read(byte[] buf, int offset, int len) is invoked on a StateInputStream, we do the following:
> - stateQueue.take() is called to grab the next message (block if no message is available)
> - Then we return the byte[] buffer of the message. The number of bytes returned is buffer.length, *not* len !
> This has 3 issues:
> #1 It violates the contract of read(): if we wanted to read len bytes at most, we cannot get more bytes back. E.g. if we wanted to read 500 bytes, but get 1000 back, then that's incorrect
> #2 If we allocate a buffer of 500 bytes, but the next message has 1000 bytes, we will get an array out of bounds exception
> #3 Even if this was correct, if we wanted to read 500 bytes, but the next message has 1000 bytes, we'd only read 500 bytes and throw the remainder away !

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 08:55:24 2011
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 18 Jul 2011 08:55:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-619) Change getState
	semantics
In-Reply-To: <23537986.1194795344719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1119556304.60247.1310993724295.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-619:
-------------------------------

Leaving the timeout in for now. Users might want to have a second line of defense to bound a state transfer.

> Change getState semantics
> -------------------------
>
>                 Key: JGRP-619
>                 URL: https://issues.jboss.org/browse/JGRP-619
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.2.9, 2.3, 2.4, 2.5
>            Reporter: Vladimir Blagojevic
>            Assignee: Vladimir Blagojevic
>             Fix For: 3.0
>
>
> Currently Channel's getState method returns boolean indicating only whether state was successfully received by state receiver and not whether it was successfully processed at relevant channel listener. This anomaly lead to convoluted application code that had to do rather complicated lock synchronization and notification mechanism on the progress of entire state transfer.
> We have to simplify this process!  State receiver should simply call blocking getState and be notified in the form of Exception of anything that went wrong; be it that state could not be received at all or that it was received but could not be installed at channel listener. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 08:55:24 2011
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 18 Jul 2011 08:55:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-619) Change getState
	semantics
In-Reply-To: <23537986.1194795344719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1492878111.60253.1310993724424.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban resolved JGRP-619.
---------------------------

    Resolution: Done


Done on branch JGRP-619

> Change getState semantics
> -------------------------
>
>                 Key: JGRP-619
>                 URL: https://issues.jboss.org/browse/JGRP-619
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.2.9, 2.3, 2.4, 2.5
>            Reporter: Vladimir Blagojevic
>            Assignee: Vladimir Blagojevic
>             Fix For: 3.0
>
>
> Currently Channel's getState method returns boolean indicating only whether state was successfully received by state receiver and not whether it was successfully processed at relevant channel listener. This anomaly lead to convoluted application code that had to do rather complicated lock synchronization and notification mechanism on the progress of entire state transfer.
> We have to simplify this process!  State receiver should simply call blocking getState and be notified in the form of Exception of anything that went wrong; be it that state could not be received at all or that it was received but could not be installed at channel listener. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 09:07:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Mon, 18 Jul 2011 09:07:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1317) Allow application
 exceptions to be defined when using the throws clause
Message-ID: <124041035.60281.1310994443638.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Allow application exceptions to be defined when using the throws clause
-----------------------------------------------------------------------

                 Key: AS7-1317
                 URL: https://issues.jboss.org/browse/AS7-1317
             Project: Application Server 7
          Issue Type: Bug
          Components: EJB
    Affects Versions: 7.0.0.Final
            Reporter: Carlo de Wolf
            Assignee: Carlo de Wolf
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 09:28:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 18 Jul 2011 09:28:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-603) Fungal 0.10.0.Beta2
In-Reply-To: <1656824651.10857.1308680183964.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <370829085.60337.1310995703894.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen updated JBJCA-603:
----------------------------------

    Summary: Fungal 0.10.0.Beta2  (was: Fungal 0.10.0.Beta1)


> Fungal 0.10.0.Beta2
> -------------------
>
>                 Key: JBJCA-603
>                 URL: https://issues.jboss.org/browse/JBJCA-603
>             Project: IronJacamar
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.1.0.Alpha1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 09:32:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 18 Jul 2011 09:32:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-630) JBoss LogManager
	1.2.0.GA
Message-ID: <167730107.60344.1310995943662.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

JBoss LogManager 1.2.0.GA
-------------------------

                 Key: JBJCA-630
                 URL: https://issues.jboss.org/browse/JBJCA-630
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.1.Final




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 09:39:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 18 Jul 2011 09:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-631) Fungal 0.10.0.Beta2
Message-ID: <1586680540.60349.1310996363710.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Fungal 0.10.0.Beta2
-------------------

                 Key: JBJCA-631
                 URL: https://issues.jboss.org/browse/JBJCA-631
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.1.Final




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 09:39:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 18 Jul 2011 09:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-628) EntirePool doesn't
	clean up
In-Reply-To: <1193791162.54268.1310666123677.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1921094518.60352.1310996363802.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen resolved JBJCA-628.
-----------------------------------

    Resolution: Done


> EntirePool doesn't clean up
> ---------------------------
>
>                 Key: JBJCA-628
>                 URL: https://issues.jboss.org/browse/JBJCA-628
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.1.Final, 1.1.0.Alpha1
>
>
> If an "EntirePool" policy or flush(true) is triggered the permits aren't cleaned up

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 09:39:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 18 Jul 2011 09:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-629) AvailableCount
	incorrect
In-Reply-To: <914405767.54269.1310666123695.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <813569884.60354.1310996363990.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen resolved JBJCA-629.
-----------------------------------

    Resolution: Done


> AvailableCount incorrect
> ------------------------
>
>                 Key: JBJCA-629
>                 URL: https://issues.jboss.org/browse/JBJCA-629
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.1.Final, 1.1.0.Alpha1
>
>
> The AvailableCount statistics is incorrectly calculated and not updated in all cases

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 10:10:23 2011
From: jira-events at lists.jboss.org (Rostislav Svoboda (JIRA))
Date: Mon, 18 Jul 2011 10:10:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1299) Interface
 resource's criteria attribute should be read-write
In-Reply-To: <1146112164.57020.1310743291902.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <798154508.60442.1310998223631.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Rostislav Svoboda commented on AS7-1299:
----------------------------------------

Detailed motivation for management-interfaces:
http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/003163.html

> Interface resource's criteria attribute should be read-write 
> -------------------------------------------------------------
>
>                 Key: AS7-1299
>                 URL: https://issues.jboss.org/browse/AS7-1299
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.0.0.Final
>            Reporter: Brian Stansberry
>             Fix For: 7.1.0.Alpha1
>
>
> http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/003123.html

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 10:18:23 2011
From: jira-events at lists.jboss.org (Rostislav Svoboda (JIRA))
Date: Mon, 18 Jul 2011 10:18:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1318)
 CommonContainerConfiguration should contain managementAddress
Message-ID: <997120400.60461.1310998703826.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

CommonContainerConfiguration should contain managementAddress
-------------------------------------------------------------

                 Key: AS7-1318
                 URL: https://issues.jboss.org/browse/AS7-1318
             Project: Application Server 7
          Issue Type: Bug
          Components: Test Suite
    Affects Versions: 7.0.0.Final
            Reporter: Rostislav Svoboda
            Assignee: Andrew Rubinger
             Fix For: 7.1.0.Alpha1


CommonContainerConfiguration (org.jboss.as.arquillian.container) should contain managementAddress.

AS7 can be configured to use different IP addresses for management and public interface. 
This could be problem for testing in remote mode.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 10:55:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 18 Jul 2011 10:55:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1319)
 size-rotating-file-handler fails with error if encoding isn't set in the
 configuration
Message-ID: <572920347.60545.1311000923789.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

size-rotating-file-handler fails with error if encoding isn't set in the configuration
--------------------------------------------------------------------------------------

                 Key: AS7-1319
                 URL: https://issues.jboss.org/browse/AS7-1319
             Project: Application Server 7
          Issue Type: Bug
          Components: Logging
    Affects Versions: 7.0.0.Final
            Reporter: jaikiran pai
            Assignee: jaikiran pai


The following size-rotating-file-handler configuration

{code:xml}
<size-rotating-file-handler name="FILE2" autoflush="true">
                <level name="TRACE"/>
                <formatter>
                    <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
                </formatter>
                <file relative-to="jboss.server.log.dir" path="server.log"/>
                <rotate-size value="2048"/>
                <max-backup-index value="5"/>
            </size-rotating-file-handler>
{code}

fails with

{code}
20:10:42,402 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC00001: Failed to start service jboss.logging.handler.FILE2: org.jboss.msc.service.StartException in service jboss.logging.handler.FILE2: java.io.UnsupportedEncodingException: undefined
	at org.jboss.as.logging.SizeRotatingFileHandlerService.start(SizeRotatingFileHandlerService.java:70)
	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_21]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_21]
	at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
Caused by: java.io.UnsupportedEncodingException: undefined
	at java.util.logging.Handler.setEncoding(Handler.java:130) [:1.6.0_21]
	at org.jboss.logmanager.handlers.OutputStreamHandler.setEncoding(OutputStreamHandler.java:90) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
	at org.jboss.as.logging.SizeRotatingFileHandlerService.start(SizeRotatingFileHandlerService.java:68)
	... 5 more
{code}





--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 10:57:23 2011
From: jira-events at lists.jboss.org (Aslak Knutsen (JIRA))
Date: Mon, 18 Jul 2011 10:57:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1318)
 CommonContainerConfiguration should contain managementAddress
In-Reply-To: <997120400.60461.1310998703826.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <525646337.60554.1311001043836.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Aslak Knutsen commented on AS7-1318:
------------------------------------

It does support it, but it's called bindAddress. Name should be changed to reflect that it's not where the container binds, but where management is bound.

> CommonContainerConfiguration should contain managementAddress
> -------------------------------------------------------------
>
>                 Key: AS7-1318
>                 URL: https://issues.jboss.org/browse/AS7-1318
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 7.0.0.Final
>            Reporter: Rostislav Svoboda
>            Assignee: Andrew Rubinger
>             Fix For: 7.1.0.Alpha1
>
>
> CommonContainerConfiguration (org.jboss.as.arquillian.container) should contain managementAddress.
> AS7 can be configured to use different IP addresses for management and public interface. 
> This could be problem for testing in remote mode.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 10:59:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 18 Jul 2011 10:59:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-689) standalone server:
 If I shutdown the server,
 the client gets a IOException->ExecutionException->EOFException("Connection
 closed")
In-Reply-To: <357534374.16951.1303984642387.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <590089586.60569.1311001163861.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on AS7-689:
--------------------------------------

I think this should only be handled cleanly if the operation is invoked via some helper API in the "helpers" packages, e.g. o.j.a.controller.client.helpers.domain.DomainClient. That's the level where logic that understands ":shutdown is going to kill the connection and that's ok" belongs. 

> standalone server: If I shutdown the server, the client gets a IOException->ExecutionException->EOFException("Connection closed")
> ---------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-689
>                 URL: https://issues.jboss.org/browse/AS7-689
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Beta3
>            Reporter: Andre Dietisheim
>
> If I shutdown the server by the following operation:
> {code}
> 	ModelNode request = new ModelNode();
> 	request.get(OP).set(SHUTDOWN);
> {code}
> the client throws a IOException because it's connection was closed. 
> The actual nesting is the following:
> IOException->ExecutionException->EOFException("Connection closed")

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 11:29:23 2011
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Mon, 18 Jul 2011 11:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-9419) Add jndi alias for
 new JBossAS7 default DS
Message-ID: <1062466775.60711.1311002963792.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Add jndi alias for new JBossAS7 default DS
------------------------------------------

                 Key: JBAS-9419
                 URL: https://issues.jboss.org/browse/JBAS-9419
             Project: Legacy JBoss Application Server 6 
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JCA service
    Affects Versions: 6.0.0.Final
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: 6.1.0


Allow for the same examples that are deployable on JBossAS7 and depend on new default DS jndi name (java:jboss/datasources/ExampleDS) to be deployable on JBossAS6 as well.
This means adding an alias that binds the two jndi names. (java:jboss/datasources/ExampleDS --> java:/DefaultDS)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 11:33:24 2011
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Mon, 18 Jul 2011 11:33:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1072) Cannot use an
 encrypted database password
In-Reply-To: <112206153.10548.1308669563619.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1045625472.60723.1311003204221.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Marcus Moyses reassigned AS7-1072:
----------------------------------

    Assignee: Marcus Moyses  (was: Stefano Maestri)


> Cannot use an encrypted database password
> -----------------------------------------
>
>                 Key: AS7-1072
>                 URL: https://issues.jboss.org/browse/AS7-1072
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 7.0.0.Beta3
>         Environment: AS7 upstream (June 21 2011)
>            Reporter: Juergen Zimmermann
>            Assignee: Marcus Moyses
>
> I'm using Jenkins build 1241. When I declare datasources in standalone.xml with  <user-name> and <password>, there is no problem.
> However, when I declare a security domain (java:/swe1DS is the datasource's jndi name):
> <security-domain name="verschluesseltesDbPassword" cache-type="default">
> 	<authentication>
> 		<login-module code="SecureIdentity" flag="required">
> 			<module-option name="username" value="swe2"/>
> 			<module-option name="password" value="..."/>
> 			<module-option name="managedConnectionFactoryName" value="jboss.jca:name=swe2DS,service=LocalTxCM"/>
> 		</login-module>
> 	</authentication>
> </security-domain>
> and changed the <security> section inside the datasource definition to
> <security-domain>verschluesseltesDbPassword</security-domain>
> then I get this stacktrace, when JBoss 7 is launched:
> 17:11:33,816 ERROR [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer] (MSC service thread 1-1) Exception during createSubject()Unauthenticated caller:null: java.lang.SecurityException: Unauthenticated caller:null
> 	at org.jboss.security.plugins.JBossSecuritySubjectFactory.createSubject(JBossSecuritySubjectFactory.java:83)
> 	at org.jboss.jca.deployers.common.AbstractDsDeployer$1.run(AbstractDsDeployer.java:979)
> 	at org.jboss.jca.deployers.common.AbstractDsDeployer$1.run(AbstractDsDeployer.java:959)
> 	at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_26]
> 	at org.jboss.jca.deployers.common.AbstractDsDeployer.createSubject(AbstractDsDeployer.java:958)
> 	at org.jboss.jca.deployers.common.AbstractDsDeployer.deployDataSource(AbstractDsDeployer.java:507)
> 	at org.jboss.jca.deployers.common.AbstractDsDeployer.createObjectsAndInjectValue(AbstractDsDeployer.java:246)
> 	at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.deploy(AbstractDataSourceService.java:241)
> 	at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:105)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 11:40:23 2011
From: jira-events at lists.jboss.org (John Bailey (JIRA))
Date: Mon, 18 Jul 2011 11:40:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1320) Parsing issue in
 Logging Subsystem - level is required by parser, but not schema
Message-ID: <1929200590.60734.1311003623635.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Parsing issue in Logging Subsystem - level is required by parser, but not schema
--------------------------------------------------------------------------------

                 Key: AS7-1320
                 URL: https://issues.jboss.org/browse/AS7-1320
             Project: Application Server 7
          Issue Type: Bug
          Components: Logging
    Affects Versions: 7.0.0.Final
            Reporter: John Bailey
            Assignee: David Lloyd
             Fix For: 7.0.1.Final


There seems to be an issue with the handler element parsing that expects the level and encoding to be defined, but they are both listed as minOccurs="0" in the schema.  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 11:42:23 2011
From: jira-events at lists.jboss.org (John Bailey (JIRA))
Date: Mon, 18 Jul 2011 11:42:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1320) Parsing issue in
 Logging Subsystem - level is required by parser, but not schema
In-Reply-To: <1929200590.60734.1311003623635.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1770058077.60737.1311003743665.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

John Bailey updated AS7-1320:
-----------------------------

    Description: 
There seems to be an issue with the handler element parsing that expects the level and encoding to be defined, but they are both listed as minOccurs="0" in the schema.  

Causes stack traces like the following:

10:31:32,371 ERROR [stderr] Exception in thread "Controller Boot Thread" java.lang.RuntimeException: org.jboss.as.controller.persistence.ConfigurationPersistenceException: Failed to parse configuration
10:31:32,371 ERROR [stderr] 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:89)
10:31:32,386 ERROR [stderr] 	at java.lang.Thread.run(Unknown Source)
10:31:32,386 ERROR [stderr] Caused by: org.jboss.as.controller.persistence.ConfigurationPersistenceException: Failed to parse configuration
10:31:32,386 ERROR [stderr] 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:115)
10:31:32,386 ERROR [stderr] 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:104)
10:31:32,386 ERROR [stderr] 	at org.jboss.as.server.ServerService.boot(ServerService.java:193)
10:31:32,386 ERROR [stderr] 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:83)
10:31:32,402 ERROR [stderr] 	... 1 more
10:31:32,402 ERROR [stderr] Caused by: java.lang.IllegalArgumentException: newValue is null
10:31:32,417 ERROR [stderr] 	at org.jboss.dmr.ModelNode.set(ModelNode.java:349)
10:31:32,417 ERROR [stderr] 	at org.jboss.as.logging.LoggingSubsystemParser.parseSizeRotatingHandlerElement(LoggingSubsystemParser.java:704)
10:31:32,417 ERROR [stderr] 	at org.jboss.as.logging.LoggingSubsystemParser.readElement(LoggingSubsystemParser.java:145)
10:31:32,417 ERROR [stderr] 	at org.jboss.as.logging.LoggingSubsystemParser.readElement(LoggingSubsystemParser.java:84)
10:31:32,417 ERROR [stderr] 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:100)
10:31:32,417 ERROR [stderr] 	at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
10:31:32,417 ERROR [stderr] 	at org.jboss.as.controller.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:311)
10:31:32,417 ERROR [stderr] 	at org.jboss.as.controller.parsing.StandaloneXml.readServerElement(StandaloneXml.java:163)
10:31:32,417 ERROR [stderr] 	at org.jboss.as.controller.parsing.StandaloneXml.readElement(StandaloneXml.java:91)
10:31:32,417 ERROR [stderr] 	at org.jboss.as.controller.parsing.StandaloneXml.readElement(StandaloneXml.java:79)
10:31:32,417 ERROR [stderr] 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:100)
10:31:32,417 ERROR [stderr] 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:59)
10:31:32,417 ERROR [stderr] 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:107)
10:31:32,417 ERROR [stderr] 	... 4 more

  was:There seems to be an issue with the handler element parsing that expects the level and encoding to be defined, but they are both listed as minOccurs="0" in the schema.  



> Parsing issue in Logging Subsystem - level is required by parser, but not schema
> --------------------------------------------------------------------------------
>
>                 Key: AS7-1320
>                 URL: https://issues.jboss.org/browse/AS7-1320
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.0.0.Final
>            Reporter: John Bailey
>            Assignee: David Lloyd
>             Fix For: 7.0.1.Final
>
>
> There seems to be an issue with the handler element parsing that expects the level and encoding to be defined, but they are both listed as minOccurs="0" in the schema.  
> Causes stack traces like the following:
> 10:31:32,371 ERROR [stderr] Exception in thread "Controller Boot Thread" java.lang.RuntimeException: org.jboss.as.controller.persistence.ConfigurationPersistenceException: Failed to parse configuration
> 10:31:32,371 ERROR [stderr] 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:89)
> 10:31:32,386 ERROR [stderr] 	at java.lang.Thread.run(Unknown Source)
> 10:31:32,386 ERROR [stderr] Caused by: org.jboss.as.controller.persistence.ConfigurationPersistenceException: Failed to parse configuration
> 10:31:32,386 ERROR [stderr] 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:115)
> 10:31:32,386 ERROR [stderr] 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:104)
> 10:31:32,386 ERROR [stderr] 	at org.jboss.as.server.ServerService.boot(ServerService.java:193)
> 10:31:32,386 ERROR [stderr] 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:83)
> 10:31:32,402 ERROR [stderr] 	... 1 more
> 10:31:32,402 ERROR [stderr] Caused by: java.lang.IllegalArgumentException: newValue is null
> 10:31:32,417 ERROR [stderr] 	at org.jboss.dmr.ModelNode.set(ModelNode.java:349)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.logging.LoggingSubsystemParser.parseSizeRotatingHandlerElement(LoggingSubsystemParser.java:704)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.logging.LoggingSubsystemParser.readElement(LoggingSubsystemParser.java:145)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.logging.LoggingSubsystemParser.readElement(LoggingSubsystemParser.java:84)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:100)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.controller.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:311)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.controller.parsing.StandaloneXml.readServerElement(StandaloneXml.java:163)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.controller.parsing.StandaloneXml.readElement(StandaloneXml.java:91)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.controller.parsing.StandaloneXml.readElement(StandaloneXml.java:79)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:100)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:59)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:107)
> 10:31:32,417 ERROR [stderr] 	... 4 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 12:29:23 2011
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Mon, 18 Jul 2011 12:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-9419) Add jndi alias for
 new JBossAS7 default DS
In-Reply-To: <1062466775.60711.1311002963792.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <209367952.60855.1311006563765.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Ales Justin commented on JBAS-9419:
-----------------------------------

e.g. this test should also pass on AS6:
Skywalker:tests-arquillian alesj$ mvn verify -Dincontainer-remote -Dtest=org.jboss.weld.tests.builtinBeans.ee.EEResourceProducerFieldPassivationCapableTest


> Add jndi alias for new JBossAS7 default DS
> ------------------------------------------
>
>                 Key: JBAS-9419
>                 URL: https://issues.jboss.org/browse/JBAS-9419
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: 6.0.0.Final
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: 6.1.0
>
>
> Allow for the same examples that are deployable on JBossAS7 and depend on new default DS jndi name (java:jboss/datasources/ExampleDS) to be deployable on JBossAS6 as well.
> This means adding an alias that binds the two jndi names. (java:jboss/datasources/ExampleDS --> java:/DefaultDS)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 12:35:23 2011
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Mon, 18 Jul 2011 12:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-9419) Add jndi alias for
 new JBossAS7 default DS
In-Reply-To: <1062466775.60711.1311002963792.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1987631184.60873.1311006923626.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Ales Justin resolved JBAS-9419.
-------------------------------

    Resolution: Done


> Add jndi alias for new JBossAS7 default DS
> ------------------------------------------
>
>                 Key: JBAS-9419
>                 URL: https://issues.jboss.org/browse/JBAS-9419
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: 6.0.0.Final
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: 6.1.0
>
>
> Allow for the same examples that are deployable on JBossAS7 and depend on new default DS jndi name (java:jboss/datasources/ExampleDS) to be deployable on JBossAS6 as well.
> This means adding an alias that binds the two jndi names. (java:jboss/datasources/ExampleDS --> java:/DefaultDS)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 13:11:23 2011
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 18 Jul 2011 13:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1279) Operation to delete
 all config file snapshots
In-Reply-To: <1067842761.52990.1310632944982.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1849968499.60940.1311009083963.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Kabir Khan resolved AS7-1279.
-----------------------------

    Resolution: Done


> Operation to delete all config file snapshots
> ---------------------------------------------
>
>                 Key: AS7-1279
>                 URL: https://issues.jboss.org/browse/AS7-1279
>             Project: Application Server 7
>          Issue Type: Feature Request
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 7.0.1.Final
>
>
> Hi,
> I was wondering using CLI (jboss-admin), can I blow away all the 
> snapshots? I see only one operation : delete-snapshot which requires the 
> "uniquely" identifiable snapshot name.
> Thx
> Vimal

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 13:21:23 2011
From: jira-events at lists.jboss.org (Marcus Moyses (JIRA))
Date: Mon, 18 Jul 2011 13:21:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1195) Failure to load
 login-module should be reported as WARNING instead of TRACE
In-Reply-To: <604271086.36476.1309909524203.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <369891689.60948.1311009683716.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Marcus Moyses resolved AS7-1195.
--------------------------------

    Resolution: Done


Merged

> Failure to load login-module should be reported as WARNING instead of TRACE
> ---------------------------------------------------------------------------
>
>                 Key: AS7-1195
>                 URL: https://issues.jboss.org/browse/AS7-1195
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Security
>    Affects Versions: 7.0.0.CR1
>         Environment: java-6-sun-1.6.0.24
> Linux ubuntu 
>            Reporter: Bruno Vernay
>            Assignee: Marcus Moyses
>             Fix For: 7.0.1.Final
>
>
> An error in standalone.xml :
> <security-domains>              
>  <security-domain ...>
>   <authentication>
>    <login-module code="database" flag="required">
> is reported in TRACE: 
> TRACE [org.jboss.security.authentication.JBossCachedAuthenticationManager] (http--127.0.0.1-8080-1) Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: database from [Module "deployment.jboss-as-login.war:main" from Service Module Loader]
> It makes it difficult to spot the error. 
> Would be easier if it was reported as a WARNING, specially since it is "required"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 13:28:23 2011
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 18 Jul 2011 13:28:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-842) Consolidate properties
 in model, xml and xsd's
In-Reply-To: <990283723.10670.1305731821029.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <418038863.60957.1311010103642.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Kabir Khan updated AS7-842:
---------------------------

      Fix Version/s: 7.1.0.Alpha1
    Forum Reference: http://lists.jboss.org/pipermail/jboss-as7-dev/2011-May/002033.html  (was: http://lists.jboss.org/pipermail/jboss-as7-dev/2011-May/002033.html)


> Consolidate properties in model, xml and xsd's
> ----------------------------------------------
>
>                 Key: AS7-842
>                 URL: https://issues.jboss.org/browse/AS7-842
>             Project: Application Server 7
>          Issue Type: Feature Request
>    Affects Versions: 7.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 7.1.0.Alpha1
>
>
> We should follow the syntax of standalone.xml's system-properties and its structure in the model. See http://lists.jboss.org/pipermail/jboss-as7-dev/2011-May/002033.html for more info

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 13:36:23 2011
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 18 Jul 2011 13:36:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-842) Consolidate
 properties in model, xml and xsd's
In-Reply-To: <990283723.10670.1305731821029.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <296696399.60967.1311010583798.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Kabir Khan commented on AS7-842:
--------------------------------

Don't touch until master is no longer used for 7.0.x releases :-)

> Consolidate properties in model, xml and xsd's
> ----------------------------------------------
>
>                 Key: AS7-842
>                 URL: https://issues.jboss.org/browse/AS7-842
>             Project: Application Server 7
>          Issue Type: Feature Request
>    Affects Versions: 7.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 7.1.0.Alpha1
>
>
> We should follow the syntax of standalone.xml's system-properties and its structure in the model. See http://lists.jboss.org/pipermail/jboss-as7-dev/2011-May/002033.html for more info

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 13:49:23 2011
From: jira-events at lists.jboss.org (John Fullard (JIRA))
Date: Mon, 18 Jul 2011 13:49:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3145) Types declared in
 DRL with no fields are not included in KnowledgeBase compiled by ChangeSet
Message-ID: <40914648.60987.1311011363628.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Types declared in DRL with no fields are not included in KnowledgeBase compiled by ChangeSet
--------------------------------------------------------------------------------------------

                 Key: JBRULES-3145
                 URL: https://issues.jboss.org/browse/JBRULES-3145
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.2.0.Final
         Environment: Drools 5.2.0 Final, Guvnor 5.2.0 Final
            Reporter: John Fullard
            Assignee: Mark Proctor


Setting up KnowledgeBase using KnowledgeAgent which is pulling package from Guvnor.  DRL declares type, which already exists in client model, with @role(event) and no fields.  Get the following stack trace when inserting an object:

java.lang.NullPointerException 
        at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:56) 
        at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:80) 
        at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:65) 
        at org.drools.common.NamedEntryPoint.createHandle(NamedEntryPoint.java:705) 
        at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:282) 
        at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:905) 
        at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:864) 
        at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:255) 
        at john.DroolsError.runRules(DroolsError.java:48) 
        at john.DroolsError.main(DroolsError.java:40) 

If the type is fully declared in the DRL, the NPE does not occur.

When compiling a DRL from a Change Set, the resulting package in the Knowledge Base does not contain declare'd types that do not contain fields; it only contains declares with at least one field. This results in a ClassObjectTypeConf with a typeDecl == null.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 14:24:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 18 Jul 2011 14:24:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1315) Console can't show
 more than 5 system properties
In-Reply-To: <329919954.59996.1310988864407.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <194554579.61025.1311013463793.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun resolved AS7-1315.
------------------------------

    Resolution: Done


> Console can't show more than 5 system properties
> ------------------------------------------------
>
>                 Key: AS7-1315
>                 URL: https://issues.jboss.org/browse/AS7-1315
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Console
>    Affects Versions: 7.0.0.Final
>            Reporter: Stan Silvert
>            Assignee: Heiko Braun
>             Fix For: 7.0.1.Final
>
>
> The console will only show the first 5 system properties.  Using the console, you can still add additional properties to standalone.xml, but they won't be displayed.
> Reported by a user in this thread: http://community.jboss.org/message/615618#615618

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 14:53:23 2011
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Mon, 18 Jul 2011 14:53:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1313) <distributable> web
 applications fail to deploy with the default configuration
In-Reply-To: <540578067.59906.1310987543621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1072269271.61063.1311015203650.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

SBS JIRA Integration updated AS7-1313:
--------------------------------------

    Forum Reference: http://community.jboss.org/message/614958#614958


> <distributable> web applications fail to deploy with the default configuration
> ------------------------------------------------------------------------------
>
>                 Key: AS7-1313
>                 URL: https://issues.jboss.org/browse/AS7-1313
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>            Reporter: Stuart Douglas
>            Assignee: Remy Maucherat
>
> <distributable> web applications fail with the following:
> "Services with missing/unavailable dependencies" => ["jboss.web.\"magnolia-bundled-webapp-4.4.4.war\" missing [ jboss.infinispan.web.___defaultcache ]"]}}}
> At the very least the user should get a better error message explaining why their deployment failed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 15:04:30 2011
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Mon, 18 Jul 2011 15:04:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1321) Upgrade to
	JBossWS-CXF 4.0.0.Beta3
Message-ID: <92893259.61080.1311015870101.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Upgrade to JBossWS-CXF 4.0.0.Beta3
----------------------------------

                 Key: AS7-1321
                 URL: https://issues.jboss.org/browse/AS7-1321
             Project: Application Server 7
          Issue Type: Component  Upgrade
          Components: Web Services
            Reporter: Alessio Soldano
            Assignee: Alessio Soldano
             Fix For: 7.1.0.Alpha1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 15:08:23 2011
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Mon, 18 Jul 2011 15:08:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1322) Provide service for
 starting/stop a POJO WS endpoint
Message-ID: <1951805285.61094.1311016103850.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Provide service for starting/stop a POJO WS endpoint
----------------------------------------------------

                 Key: AS7-1322
                 URL: https://issues.jboss.org/browse/AS7-1322
             Project: Application Server 7
          Issue Type: Feature Request
          Components: Web Services
            Reporter: Alessio Soldano
            Assignee: Alessio Soldano
             Fix For: 7.1.0.Alpha1


We need a service for programatically publishing a WS endpoint on JBoss AS 7 HTTP server. There's recently been a mild interest from the community for this and the functionality would be of great use to projects like XTS requiring publishing of endpoints as part of their subsystem boot.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 21:44:23 2011
From: jira-events at lists.jboss.org (Abhijit Sarkar (JIRA))
Date: Mon, 18 Jul 2011 21:44:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1323) @Resource injection
 on WebServiceContext fails
Message-ID: <48156148.61562.1311039863763.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

@Resource injection on WebServiceContext fails
----------------------------------------------

                 Key: AS7-1323
                 URL: https://issues.jboss.org/browse/AS7-1323
             Project: Application Server 7
          Issue Type: Bug
          Components: Web Services
    Affects Versions: 7.0.0.Final
         Environment: Ubuntu 11.04 64 bit, Sun Java 1.6.0_26, JBoss AS 7.0.0.Final
            Reporter: Abhijit Sarkar
            Assignee: Alessio Soldano


00:20:55,004 WARN  [org.jboss.as.ee.component.ResourceInjectionAnnotationParsingProcessor] (MSC service thread 1-4) Can't handle @Resource for ENC name: MovieServiceRestful/wsCtx on class MovieServiceRestful since it's missing a "lookup" (or "mappedName") value and isn't of any known type.

@WebServiceProvider
@BindingType(value = HTTPBinding.HTTP_BINDING)
public class MovieServiceRestful implements Provider<Source> {

    @Resource
    protected WebServiceContext wsCtx;

    ...
}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 21:50:23 2011
From: jira-events at lists.jboss.org (Abhijit Sarkar (JIRA))
Date: Mon, 18 Jul 2011 21:50:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1324) RESTful service
 Servlet configuration fails with ClassCastException
Message-ID: <938495355.61579.1311040223621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

RESTful service Servlet configuration fails with ClassCastException
-------------------------------------------------------------------

                 Key: AS7-1324
                 URL: https://issues.jboss.org/browse/AS7-1324
             Project: Application Server 7
          Issue Type: Bug
          Components: Web Services
    Affects Versions: 7.0.0.Final
         Environment: Ubuntu 11.04 64 bit, Sun Java 1.6.0_26, JBoss AS 7.0.0.Final 
            Reporter: Abhijit Sarkar
            Assignee: Alessio Soldano


RESTful service fails to deploy with following exception when configured as a Servlet in web.xml. If not configured in web.xml, the service is unavailable on the deployed context path.

00:29:32,684 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/movieservicerestful].[MovieServiceRestful]] (http--127.0.0.1-9090-2) Allocate exception for servlet MovieServiceRestful: java.lang.ClassCastException: MovieServiceRestful cannot be cast to javax.servlet.Servlet

<servlet>
  <servlet-name>MovieServiceRestful</servlet-name>
  <servlet-class>MovieServiceRestful</servlet-class>
</servlet>

<servlet-mapping>
  <servlet-name>MovieServiceRestful</servlet-name>
  <url-pattern>/*</url-pattern>
</servlet-mapping>

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 18 23:37:26 2011
From: jira-events at lists.jboss.org (Abhijit Sarkar (JIRA))
Date: Mon, 18 Jul 2011 23:37:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1324) RESTful service
 Servlet configuration fails with ClassCastException
In-Reply-To: <938495355.61579.1311040223621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1546342839.61666.1311046646938.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Abhijit Sarkar commented on AS7-1324:
-------------------------------------

While the above worked on AS 6.0.0.Final, it does not work on 7.0.0.Final. Instead, I am having to configure RESTEasy as follows. Isn't it be possible to totally do away with the web.xml with Java EE 6?

<context-param>
  <param-name>resteasy.scan</param-name>
  <param-value>true</param-value>
</context-param>
<listener>
  <listener-class>org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap</listener-class>
</listener>
<servlet>
  <servlet-name>Resteasy</servlet-name>
  <servlet-class>org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher</servlet-class>
</servlet>
<servlet-mapping>
  <servlet-name>Resteasy</servlet-name>
  <url-pattern>/*</url-pattern>
</servlet-mapping>  

> RESTful service Servlet configuration fails with ClassCastException
> -------------------------------------------------------------------
>
>                 Key: AS7-1324
>                 URL: https://issues.jboss.org/browse/AS7-1324
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>         Environment: Ubuntu 11.04 64 bit, Sun Java 1.6.0_26, JBoss AS 7.0.0.Final 
>            Reporter: Abhijit Sarkar
>            Assignee: Alessio Soldano
>
> RESTful service fails to deploy with following exception when configured as a Servlet in web.xml. If not configured in web.xml, the service is unavailable on the deployed context path.
> 00:29:32,684 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/movieservicerestful].[MovieServiceRestful]] (http--127.0.0.1-9090-2) Allocate exception for servlet MovieServiceRestful: java.lang.ClassCastException: MovieServiceRestful cannot be cast to javax.servlet.Servlet
> <servlet>
>   <servlet-name>MovieServiceRestful</servlet-name>
>   <servlet-class>MovieServiceRestful</servlet-class>
> </servlet>
> <servlet-mapping>
>   <servlet-name>MovieServiceRestful</servlet-name>
>   <url-pattern>/*</url-pattern>
> </servlet-mapping>

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 00:14:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Tue, 19 Jul 2011 00:14:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1182) Incorrect security
 domain selected for web application.
In-Reply-To: <320201656.33784.1309788924180.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1334247076.61673.1311048863826.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Juergen Zimmermann commented on AS7-1182:
-----------------------------------------

I realized that the JNDI names for security domains changed, e.g. java:jboss/jaas/test instead of java:/jaas/test as it was in JBoss 4.2, 5 and 6. But this didn't help either.

The relevant output of "jboss-admin -c command=/subsystem=naming:jndi-view" :
{
    "outcome" => "success",
    "result" => {
        "java: contexts" => {
            "java:jboss" => {
                "jaas" => {
                    "class-name" => "org.jboss.as.naming.context.ModularReference",
                    "children" => {
                        "test" => {
                            "class-name" => "org.jboss.as.security.plugins.SecurityDomainContext",
                            "value" => "org.jboss.security.authentication.JBossCachedAuthenticationManager at 17b55e6"
                        },
                        "swe" => {
                            "class-name" => "org.jboss.as.security.plugins.SecurityDomainContext",
                            "value" => "org.jboss.security.authentication.JBossCachedAuthenticationManager at 448b7f"
                        },
                        "other" => {
                            "class-name" => "org.jboss.as.security.plugins.SecurityDomainContext",
                            "value" => "org.jboss.security.authentication.JBossCachedAuthenticationManager at 224002"
                        },
                        "verschluesseltesDbPassword" => {
                            "class-name" => "org.jboss.as.security.plugins.SecurityDomainContext",
                            "value" => "org.jboss.security.authentication.JBossCachedAuthenticationManager at 9875a3"
                        }
                    }
                },
                ...


> Incorrect security domain selected for web application.
> -------------------------------------------------------
>
>                 Key: AS7-1182
>                 URL: https://issues.jboss.org/browse/AS7-1182
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: Darran Lofthouse
>         Attachments: test.ear.zip, testcase-src.zip
>
>
> I want to migrate from JBossAS 6 to 7.0.0.CR1. In standalone.xml I declare the following security domain, but get the stacktrace (see below) looking for UsersRolesLoginModule instead of DatabaseServerLoginModule.
> Security domain in standalone.xml:
>    <security-domain name="swe2" cache-type="default">
>       <authentication>
>          <login-module code="Database" flag="required">
>             <module-option name="dsJndiName" value="java:/swe2DS"/>
>             <module-option name="unauthenticatedIdentity" value="gast"/>
>             <module-option name="principalsQuery" value="SELECT password FROM kunde WHERE username=?"/>
>             <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM swe2_role r INNER JOIN kunde k ON r.kunde_fk = k.k_id WHERE k.username=?"/>
>             <module-option name="hashAlgorithm" value="SHA-1"/>
>             <module-option name="hashEncoding" value="base64"/>
>          </login-module>
>       </authentication>
>    </security-domain>
> Stacktrace regarding UsersRolesLoginModule (instead of DatabaseServerLoginModule):
> 16:03:58,528 ERROR [org.jboss.security.auth.spi.UsersRolesLoginModule] (http--127.0.0.1-8080-2) Failed to load users/passwords/role files: java.io.IOException: No properties file: users.properties or defaults: defaultUsers.properties found
> 	at org.jboss.security.auth.spi.Util.loadProperties(Util.java:227) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:188) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:202) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:129) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	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 javax.security.auth.login.LoginContext.invoke(LoginContext.java:756) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683) [:1.6.0_26]
> 	at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:579) [:1.6.0_26]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:411) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:154) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:127) [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:180) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:446) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 01:02:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 19 Jul 2011 01:02:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1323) @Resource injection
 on WebServiceContext fails
In-Reply-To: <48156148.61562.1311039863763.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1884589405.61741.1311051743656.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on AS7-1323:
-----------------------------------

Let's first make sure you are running the "standalone-preview.xml" configuration in the "everything" profile.

> @Resource injection on WebServiceContext fails
> ----------------------------------------------
>
>                 Key: AS7-1323
>                 URL: https://issues.jboss.org/browse/AS7-1323
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>         Environment: Ubuntu 11.04 64 bit, Sun Java 1.6.0_26, JBoss AS 7.0.0.Final
>            Reporter: Abhijit Sarkar
>            Assignee: Alessio Soldano
>
> 00:20:55,004 WARN  [org.jboss.as.ee.component.ResourceInjectionAnnotationParsingProcessor] (MSC service thread 1-4) Can't handle @Resource for ENC name: MovieServiceRestful/wsCtx on class MovieServiceRestful since it's missing a "lookup" (or "mappedName") value and isn't of any known type.
> @WebServiceProvider
> @BindingType(value = HTTPBinding.HTTP_BINDING)
> public class MovieServiceRestful implements Provider<Source> {
>     @Resource
>     protected WebServiceContext wsCtx;
>     ...
> }

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 01:02:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 19 Jul 2011 01:02:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1324) RESTful service
 Servlet configuration fails with ClassCastException
In-Reply-To: <938495355.61579.1311040223621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1982302997.61745.1311051743786.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on AS7-1324:
-----------------------------------

Let's first make sure you are running the "standalone-preview.xml" configuration in the "everything" profile.


> RESTful service Servlet configuration fails with ClassCastException
> -------------------------------------------------------------------
>
>                 Key: AS7-1324
>                 URL: https://issues.jboss.org/browse/AS7-1324
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>         Environment: Ubuntu 11.04 64 bit, Sun Java 1.6.0_26, JBoss AS 7.0.0.Final 
>            Reporter: Abhijit Sarkar
>            Assignee: Alessio Soldano
>
> RESTful service fails to deploy with following exception when configured as a Servlet in web.xml. If not configured in web.xml, the service is unavailable on the deployed context path.
> 00:29:32,684 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/movieservicerestful].[MovieServiceRestful]] (http--127.0.0.1-9090-2) Allocate exception for servlet MovieServiceRestful: java.lang.ClassCastException: MovieServiceRestful cannot be cast to javax.servlet.Servlet
> <servlet>
>   <servlet-name>MovieServiceRestful</servlet-name>
>   <servlet-class>MovieServiceRestful</servlet-class>
> </servlet>
> <servlet-mapping>
>   <servlet-name>MovieServiceRestful</servlet-name>
>   <url-pattern>/*</url-pattern>
> </servlet-mapping>

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 03:00:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 19 Jul 2011 03:00:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1325) Cannot create
 dependency on SNAPSHOT bundle
Message-ID: <471724515.61845.1311058823973.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Cannot create dependency on SNAPSHOT bundle
-------------------------------------------

                 Key: AS7-1325
                 URL: https://issues.jboss.org/browse/AS7-1325
             Project: Application Server 7
          Issue Type: Bug
    Affects Versions: 7.0.0.Final
            Reporter: Thomas Diesler
            Assignee: Thomas Diesler


08:32:24,892 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 1) Deployment of "jboss-osgi-example-jbossas-webapp-1.0.0-SNAPSHOT.war" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"jboss-osgi-example-jbossas-webapp-1.0.0-SNAPSHOT.war\".CONFIGURE_MODULE missing [ jboss.module.information.service.\"deployment.jboss-osgi-example-jbossas-bundle\".\"1.0.0-SNAPSHOT\" ]"]}
08:32:24,893 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 1) Service status report
   New missing/unsatisfied dependencies:
      service jboss.module.information.service."deployment.jboss-osgi-example-jbossas-bundle"."1.0.0-SNAPSHOT" (missing)


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 03:00:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 19 Jul 2011 03:00:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1325) Cannot create
 dependency on SNAPSHOT bundle
In-Reply-To: <471724515.61845.1311058823973.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1255245096.61846.1311058823995.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Thomas Diesler updated AS7-1325:
--------------------------------

    Description: 
{code}
08:32:24,892 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 1) Deployment of "jboss-osgi-example-jbossas-webapp-1.0.0-SNAPSHOT.war" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"jboss-osgi-example-jbossas-webapp-1.0.0-SNAPSHOT.war\".CONFIGURE_MODULE missing [ jboss.module.information.service.\"deployment.jboss-osgi-example-jbossas-bundle\".\"1.0.0-SNAPSHOT\" ]"]}
08:32:24,893 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 1) Service status report
   New missing/unsatisfied dependencies:
      service jboss.module.information.service."deployment.jboss-osgi-example-jbossas-bundle"."1.0.0-SNAPSHOT" (missing)
{code}

  was:
08:32:24,892 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 1) Deployment of "jboss-osgi-example-jbossas-webapp-1.0.0-SNAPSHOT.war" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"jboss-osgi-example-jbossas-webapp-1.0.0-SNAPSHOT.war\".CONFIGURE_MODULE missing [ jboss.module.information.service.\"deployment.jboss-osgi-example-jbossas-bundle\".\"1.0.0-SNAPSHOT\" ]"]}
08:32:24,893 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 1) Service status report
   New missing/unsatisfied dependencies:
      service jboss.module.information.service."deployment.jboss-osgi-example-jbossas-bundle"."1.0.0-SNAPSHOT" (missing)




> Cannot create dependency on SNAPSHOT bundle
> -------------------------------------------
>
>                 Key: AS7-1325
>                 URL: https://issues.jboss.org/browse/AS7-1325
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Final
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>
> {code}
> 08:32:24,892 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 1) Deployment of "jboss-osgi-example-jbossas-webapp-1.0.0-SNAPSHOT.war" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"jboss-osgi-example-jbossas-webapp-1.0.0-SNAPSHOT.war\".CONFIGURE_MODULE missing [ jboss.module.information.service.\"deployment.jboss-osgi-example-jbossas-bundle\".\"1.0.0-SNAPSHOT\" ]"]}
> 08:32:24,893 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 1) Service status report
>    New missing/unsatisfied dependencies:
>       service jboss.module.information.service."deployment.jboss-osgi-example-jbossas-bundle"."1.0.0-SNAPSHOT" (missing)
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 03:00:24 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 19 Jul 2011 03:00:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1325) Cannot create
 dependency on SNAPSHOT bundle
In-Reply-To: <471724515.61845.1311058823973.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <81424575.61850.1311058824094.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Thomas Diesler updated AS7-1325:
--------------------------------

    Description: 
08:32:24,892 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 1) Deployment of "jboss-osgi-example-jbossas-webapp-1.0.0-SNAPSHOT.war" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"jboss-osgi-example-jbossas-webapp-1.0.0-SNAPSHOT.war\".CONFIGURE_MODULE missing [ jboss.module.information.service.\"deployment.jboss-osgi-example-jbossas-bundle\".\"1.0.0-SNAPSHOT\" ]"]}
08:32:24,893 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 1) Service status report
   New missing/unsatisfied dependencies:
      service jboss.module.information.service."deployment.jboss-osgi-example-jbossas-bundle"."1.0.0-SNAPSHOT" (missing)


  was:
{code}
08:32:24,892 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 1) Deployment of "jboss-osgi-example-jbossas-webapp-1.0.0-SNAPSHOT.war" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"jboss-osgi-example-jbossas-webapp-1.0.0-SNAPSHOT.war\".CONFIGURE_MODULE missing [ jboss.module.information.service.\"deployment.jboss-osgi-example-jbossas-bundle\".\"1.0.0-SNAPSHOT\" ]"]}
08:32:24,893 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 1) Service status report
   New missing/unsatisfied dependencies:
      service jboss.module.information.service."deployment.jboss-osgi-example-jbossas-bundle"."1.0.0-SNAPSHOT" (missing)
{code}



> Cannot create dependency on SNAPSHOT bundle
> -------------------------------------------
>
>                 Key: AS7-1325
>                 URL: https://issues.jboss.org/browse/AS7-1325
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Final
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>
> 08:32:24,892 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 1) Deployment of "jboss-osgi-example-jbossas-webapp-1.0.0-SNAPSHOT.war" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"jboss-osgi-example-jbossas-webapp-1.0.0-SNAPSHOT.war\".CONFIGURE_MODULE missing [ jboss.module.information.service.\"deployment.jboss-osgi-example-jbossas-bundle\".\"1.0.0-SNAPSHOT\" ]"]}
> 08:32:24,893 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 1) Service status report
>    New missing/unsatisfied dependencies:
>       service jboss.module.information.service."deployment.jboss-osgi-example-jbossas-bundle"."1.0.0-SNAPSHOT" (missing)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 03:11:23 2011
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Tue, 19 Jul 2011 03:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1283) Cookie-Based Sessions
	Broken
In-Reply-To: <125463836.53501.1310646803618.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <422749181.61863.1311059483828.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

SBS JIRA Integration updated AS7-1283:
--------------------------------------

    Forum Reference: http://community.jboss.org/message/612640#612640


> Cookie-Based Sessions Broken
> ----------------------------
>
>                 Key: AS7-1283
>                 URL: https://issues.jboss.org/browse/AS7-1283
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Final
>            Reporter: Benjamin Browning
>            Assignee: Remy Maucherat
>            Priority: Blocker
>             Fix For: 7.0.1.Final
>
>
> See http://community.jboss.org/message/612763 and http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/003120.html.
> Essentially cookie-based sessions are broken in major browsers and curl unless -Dorg.apache.tomcat.util.http.ServerCookie.FWD_SLASH_IS_SEPARATOR=false is passed on boot. It's likely a large percentage of the people that try AS7 Final will run into this issue and have to spend time trying to figure out why sessions aren't working.
> To summarize the above links, what's happening is the cookie's Path value is being enclosed in quotes. Browsers don't expect this and thus when the browser receives a cookie it doesn't send that cookie back on subsequent requests because the browser doesn't think the cookie's Path value matches the user's path.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 03:11:24 2011
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Tue, 19 Jul 2011 03:11:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1283) Cookie-Based Sessions
	Broken
In-Reply-To: <125463836.53501.1310646803618.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1210838020.61879.1311059484316.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

SBS JIRA Integration updated AS7-1283:
--------------------------------------

    Forum Reference: http://community.jboss.org/message/615870#615870, http://community.jboss.org/message/612640#612640  (was: http://community.jboss.org/message/612640#612640)


> Cookie-Based Sessions Broken
> ----------------------------
>
>                 Key: AS7-1283
>                 URL: https://issues.jboss.org/browse/AS7-1283
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Final
>            Reporter: Benjamin Browning
>            Assignee: Remy Maucherat
>            Priority: Blocker
>             Fix For: 7.0.1.Final
>
>
> See http://community.jboss.org/message/612763 and http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/003120.html.
> Essentially cookie-based sessions are broken in major browsers and curl unless -Dorg.apache.tomcat.util.http.ServerCookie.FWD_SLASH_IS_SEPARATOR=false is passed on boot. It's likely a large percentage of the people that try AS7 Final will run into this issue and have to spend time trying to figure out why sessions aren't working.
> To summarize the above links, what's happening is the cookie's Path value is being enclosed in quotes. Browsers don't expect this and thus when the browser receives a cookie it doesn't send that cookie back on subsequent requests because the browser doesn't think the cookie's Path value matches the user's path.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 03:14:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 19 Jul 2011 03:14:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1326) Cannot redeploy OSGi
 bundle that is wired to webapp
Message-ID: <398461489.61884.1311059663616.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Cannot redeploy OSGi bundle that is wired to webapp
---------------------------------------------------

                 Key: AS7-1326
                 URL: https://issues.jboss.org/browse/AS7-1326
             Project: Application Server 7
          Issue Type: Bug
    Affects Versions: 7.0.0.Final
            Reporter: Thomas Diesler
            Assignee: Thomas Diesler


{code}
09:12:12,719 ERROR [org.jboss.msc.service] (MSC service thread 1-1) MSC00002: Invocation of listener "org.jboss.as.osgi.deployment.BundleStartTracker$1 at 2789a406" failed: org.jboss.msc.service.DuplicateServiceException: Service jboss.module.spec.service."deployment.jboss-osgi-example-jbossas-bundle"."0.0.0" is already registered
	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:154)
	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:226)
	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:560)
	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201)
	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2194)
	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:307)
	at org.jboss.as.osgi.service.ModuleLoaderIntegration.addModule(ModuleLoaderIntegration.java:122)
	at org.jboss.osgi.framework.internal.ModuleManagerPlugin.createHostModule(ModuleManagerPlugin.java:340)
	at org.jboss.osgi.framework.internal.ModuleManagerPlugin.addModule(ModuleManagerPlugin.java:225)
	at org.jboss.osgi.framework.internal.ResolverPlugin.addModules(ResolverPlugin.java:248)
	at org.jboss.osgi.framework.internal.ResolverPlugin.applyResolverResults(ResolverPlugin.java:226)
	at org.jboss.osgi.framework.internal.ResolverPlugin.resolve(ResolverPlugin.java:161)
	at org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:551)
	at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:210)
	at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:494)
	at org.jboss.as.osgi.deployment.BundleStartTracker$1.processService(BundleStartTracker.java:146)
	at org.jboss.as.osgi.deployment.BundleStartTracker$1.transition(BundleStartTracker.java:121)
{code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 03:16:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 19 Jul 2011 03:16:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1326) Cannot redeploy OSGi
 bundle that is wired to webapp
In-Reply-To: <398461489.61884.1311059663616.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <75244146.61886.1311059783768.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Thomas Diesler updated AS7-1326:
--------------------------------

    Component/s: OSGi


> Cannot redeploy OSGi bundle that is wired to webapp
> ---------------------------------------------------
>
>                 Key: AS7-1326
>                 URL: https://issues.jboss.org/browse/AS7-1326
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: OSGi
>    Affects Versions: 7.0.0.Final
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>
> {code}
> 09:12:12,719 ERROR [org.jboss.msc.service] (MSC service thread 1-1) MSC00002: Invocation of listener "org.jboss.as.osgi.deployment.BundleStartTracker$1 at 2789a406" failed: org.jboss.msc.service.DuplicateServiceException: Service jboss.module.spec.service."deployment.jboss-osgi-example-jbossas-bundle"."0.0.0" is already registered
> 	at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:154)
> 	at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:226)
> 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:560)
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201)
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2194)
> 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:307)
> 	at org.jboss.as.osgi.service.ModuleLoaderIntegration.addModule(ModuleLoaderIntegration.java:122)
> 	at org.jboss.osgi.framework.internal.ModuleManagerPlugin.createHostModule(ModuleManagerPlugin.java:340)
> 	at org.jboss.osgi.framework.internal.ModuleManagerPlugin.addModule(ModuleManagerPlugin.java:225)
> 	at org.jboss.osgi.framework.internal.ResolverPlugin.addModules(ResolverPlugin.java:248)
> 	at org.jboss.osgi.framework.internal.ResolverPlugin.applyResolverResults(ResolverPlugin.java:226)
> 	at org.jboss.osgi.framework.internal.ResolverPlugin.resolve(ResolverPlugin.java:161)
> 	at org.jboss.osgi.framework.internal.AbstractBundleState.ensureResolved(AbstractBundleState.java:551)
> 	at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:210)
> 	at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:494)
> 	at org.jboss.as.osgi.deployment.BundleStartTracker$1.processService(BundleStartTracker.java:146)
> 	at org.jboss.as.osgi.deployment.BundleStartTracker$1.transition(BundleStartTracker.java:121)
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 03:16:24 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 19 Jul 2011 03:16:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1325) Cannot create
 dependency on SNAPSHOT bundle
In-Reply-To: <471724515.61845.1311058823973.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1516925900.61896.1311059784261.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Thomas Diesler updated AS7-1325:
--------------------------------

    Component/s: OSGi


> Cannot create dependency on SNAPSHOT bundle
> -------------------------------------------
>
>                 Key: AS7-1325
>                 URL: https://issues.jboss.org/browse/AS7-1325
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: OSGi
>    Affects Versions: 7.0.0.Final
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>
> 08:32:24,892 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 1) Deployment of "jboss-osgi-example-jbossas-webapp-1.0.0-SNAPSHOT.war" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"jboss-osgi-example-jbossas-webapp-1.0.0-SNAPSHOT.war\".CONFIGURE_MODULE missing [ jboss.module.information.service.\"deployment.jboss-osgi-example-jbossas-bundle\".\"1.0.0-SNAPSHOT\" ]"]}
> 08:32:24,893 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 1) Service status report
>    New missing/unsatisfied dependencies:
>       service jboss.module.information.service."deployment.jboss-osgi-example-jbossas-bundle"."1.0.0-SNAPSHOT" (missing)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 03:27:23 2011
From: jira-events at lists.jboss.org (Rostislav Svoboda (JIRA))
Date: Tue, 19 Jul 2011 03:27:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1318)
 CommonContainerConfiguration should contain managementAddress
In-Reply-To: <997120400.60461.1310998703826.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <468984146.61918.1311060443827.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Rostislav Svoboda commented on AS7-1318:
----------------------------------------

So why are in CommonContainerConfiguration attributes httpPort and jmxPort? ARQ must know that jmx and http are accessible on 10.34.3.154 and management is accessible on 127.0.0.1.

{code}
    <interfaces>
        <interface name="management">
            <inet-address value="127.0.0.1"/>
        </interface>
        <interface name="publicIP">
            <inet-address value="10.34.3.154"/>
        </interface>
    </interfaces>
    <socket-binding-group name="standard-sockets" default-interface="publicIP">
        <socket-binding name="http" port="8080"/>
        <socket-binding name="https" port="8443"/>
        <socket-binding name="jmx-connector-registry" port="1090"/>
        <socket-binding name="jmx-connector-server" port="1091"/>
        <socket-binding name="jndi" port="1099"/>
        <socket-binding name="osgi-http" port="8090"/>
        <socket-binding name="remoting" port="4447"/>
        <socket-binding name="txn-recovery-environment" port="4712"/>
        <socket-binding name="txn-status-manager" port="4713"/>
    </socket-binding-group>
{code}

> CommonContainerConfiguration should contain managementAddress
> -------------------------------------------------------------
>
>                 Key: AS7-1318
>                 URL: https://issues.jboss.org/browse/AS7-1318
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 7.0.0.Final
>            Reporter: Rostislav Svoboda
>            Assignee: Andrew Rubinger
>             Fix For: 7.1.0.Alpha1
>
>
> CommonContainerConfiguration (org.jboss.as.arquillian.container) should contain managementAddress.
> AS7 can be configured to use different IP addresses for management and public interface. 
> This could be problem for testing in remote mode.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 03:27:24 2011
From: jira-events at lists.jboss.org (Rostislav Svoboda (JIRA))
Date: Tue, 19 Jul 2011 03:27:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1318)
 CommonContainerConfiguration should contain managementAddress
In-Reply-To: <997120400.60461.1310998703826.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1757895070.61934.1311060444547.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Rostislav Svoboda commented on AS7-1318:
----------------------------------------

I would expect both properties bindAddress and managementAddress in CommonContainerConfiguration. But maybe I'm missing something.

> CommonContainerConfiguration should contain managementAddress
> -------------------------------------------------------------
>
>                 Key: AS7-1318
>                 URL: https://issues.jboss.org/browse/AS7-1318
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 7.0.0.Final
>            Reporter: Rostislav Svoboda
>            Assignee: Andrew Rubinger
>             Fix For: 7.1.0.Alpha1
>
>
> CommonContainerConfiguration (org.jboss.as.arquillian.container) should contain managementAddress.
> AS7 can be configured to use different IP addresses for management and public interface. 
> This could be problem for testing in remote mode.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 03:33:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 19 Jul 2011 03:33:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1327) Manage EJB Container
 through web console
Message-ID: <411988549.61956.1311060803632.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Manage EJB Container through web console
----------------------------------------

                 Key: AS7-1327
                 URL: https://issues.jboss.org/browse/AS7-1327
             Project: Application Server 7
          Issue Type: Feature Request
          Components: Console
            Reporter: Heiko Braun
            Assignee: Heiko Braun
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 03:35:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 19 Jul 2011 03:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (AS7-1327) Manage EJB Container
 through web console
Message-ID: <291402328.61959.1311060923617.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun deleted AS7-1327:
-----------------------------


> Manage EJB Container through web console
> ----------------------------------------
>
>                 Key: AS7-1327
>                 URL: https://issues.jboss.org/browse/AS7-1327
>             Project: Application Server 7
>          Issue Type: Feature Request
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 03:39:24 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 19 Jul 2011 03:39:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-913) provide management
 operation for the EJB container
In-Reply-To: <1527474149.31703.1306501741272.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <84183110.61971.1311061164082.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun updated AS7-913:
----------------------------

    Fix Version/s: 7.1.0.Beta1
                       (was: 7.1.0.CR1)


> provide management operation for the EJB container
> --------------------------------------------------
>
>                 Key: AS7-913
>                 URL: https://issues.jboss.org/browse/AS7-913
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Domain Management, EJB
>            Reporter: Heiko Braun
>            Assignee: Carlo de Wolf
>              Labels: console_prio
>             Fix For: 7.1.0.Beta1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 03:43:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 19 Jul 2011 03:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1329) Manage common HA
 capabilities through the console
Message-ID: <1511755616.61994.1311061403657.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Manage common HA capabilities through the console
-------------------------------------------------

                 Key: AS7-1329
                 URL: https://issues.jboss.org/browse/AS7-1329
             Project: Application Server 7
          Issue Type: Feature Request
          Components: Console
            Reporter: Heiko Braun
            Assignee: Heiko Braun
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 03:43:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 19 Jul 2011 03:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1328) Manage thread pools
 through the web interface
Message-ID: <1559209190.61993.1311061403638.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Manage thread pools through the web interface
---------------------------------------------

                 Key: AS7-1328
                 URL: https://issues.jboss.org/browse/AS7-1328
             Project: Application Server 7
          Issue Type: Feature Request
          Components: Console
            Reporter: Heiko Braun
            Assignee: Heiko Braun
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 03:45:24 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 19 Jul 2011 03:45:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1330) Manage web sessions
 and session replication
Message-ID: <1183291259.61999.1311061524157.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Manage web sessions and session replication
-------------------------------------------

                 Key: AS7-1330
                 URL: https://issues.jboss.org/browse/AS7-1330
             Project: Application Server 7
          Issue Type: Sub-task
          Components: Console
            Reporter: Heiko Braun
            Assignee: Heiko Braun
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 03:45:24 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 19 Jul 2011 03:45:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1331) Manage stateful
 session bean replication settings
Message-ID: <944967438.62002.1311061524228.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Manage stateful session bean replication settings
-------------------------------------------------

                 Key: AS7-1331
                 URL: https://issues.jboss.org/browse/AS7-1331
             Project: Application Server 7
          Issue Type: Sub-task
          Components: Console
            Reporter: Heiko Braun
            Assignee: Heiko Braun
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 03:47:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 19 Jul 2011 03:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-913) provide management
 operation for the EJB container
In-Reply-To: <1527474149.31703.1306501741272.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <142356768.62005.1311061643665.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun commented on AS7-913:
---------------------------------

failover: AS7-1331

> provide management operation for the EJB container
> --------------------------------------------------
>
>                 Key: AS7-913
>                 URL: https://issues.jboss.org/browse/AS7-913
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Domain Management, EJB
>            Reporter: Heiko Braun
>            Assignee: Carlo de Wolf
>              Labels: console_prio
>             Fix For: 7.1.0.Beta1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 03:49:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 19 Jul 2011 03:49:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1332) En/disable JVM debug
 options from web interface
Message-ID: <1777509822.62008.1311061763610.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

En/disable JVM debug options from web interface
-----------------------------------------------

                 Key: AS7-1332
                 URL: https://issues.jboss.org/browse/AS7-1332
             Project: Application Server 7
          Issue Type: Feature Request
          Components: Console
            Reporter: Heiko Braun
            Assignee: Heiko Braun
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 03:51:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 19 Jul 2011 03:51:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1333) Expose web container
 runtime stats through the web console
Message-ID: <803287070.62011.1311061883621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Expose web container runtime stats through the web console
----------------------------------------------------------

                 Key: AS7-1333
                 URL: https://issues.jboss.org/browse/AS7-1333
             Project: Application Server 7
          Issue Type: Feature Request
          Components: Console
            Reporter: Heiko Braun
            Assignee: Heiko Braun
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 03:53:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 19 Jul 2011 03:53:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1333) Expose web
 container runtime stats through the web console
In-Reply-To: <803287070.62011.1311061883621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1032285637.62015.1311062003687.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun commented on AS7-1333:
----------------------------------

i.e 

- http connections in-use
- thread usage
- response time

whatever seems reasonable

> Expose web container runtime stats through the web console
> ----------------------------------------------------------
>
>                 Key: AS7-1333
>                 URL: https://issues.jboss.org/browse/AS7-1333
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Console
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 7.1.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 03:53:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 19 Jul 2011 03:53:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1334) Expose JMS runtime
 stats through console
Message-ID: <2119564700.62018.1311062003746.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Expose JMS runtime stats through console
----------------------------------------

                 Key: AS7-1334
                 URL: https://issues.jboss.org/browse/AS7-1334
             Project: Application Server 7
          Issue Type: Feature Request
          Components: Console
            Reporter: Heiko Braun
            Assignee: Heiko Braun
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 03:55:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 19 Jul 2011 03:55:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1335) Manage security
 realms through web console
Message-ID: <284718837.62024.1311062123643.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Manage security realms through web console
------------------------------------------

                 Key: AS7-1335
                 URL: https://issues.jboss.org/browse/AS7-1335
             Project: Application Server 7
          Issue Type: Feature Request
          Components: Console
            Reporter: Heiko Braun
            Assignee: Heiko Braun
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 03:55:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 19 Jul 2011 03:55:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1336) Configure message
 security through console (JMS/WS)
Message-ID: <488972814.62025.1311062123662.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Configure message security through console (JMS/WS)
---------------------------------------------------

                 Key: AS7-1336
                 URL: https://issues.jboss.org/browse/AS7-1336
             Project: Application Server 7
          Issue Type: Feature Request
          Components: Console
            Reporter: Heiko Braun
            Assignee: Heiko Braun
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 04:25:23 2011
From: jira-events at lists.jboss.org (Karel Piwko (JIRA))
Date: Tue, 19 Jul 2011 04:25:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1337) Expose Management API
	for tests
Message-ID: <1998494488.62084.1311063923613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Expose Management API for tests
-------------------------------

                 Key: AS7-1337
                 URL: https://issues.jboss.org/browse/AS7-1337
             Project: Application Server 7
          Issue Type: Feature Request
          Components: Test Suite
    Affects Versions: 7.0.0.Final
            Reporter: Karel Piwko
            Assignee: Andrew Rubinger
            Priority: Critical


It should be possible to get access to management console/API from the test suite. There is a ModelControllerClient available in CommonDeployableContainer but this is not exposed to user. Creating it externally requires keeping configuration twice.

The client can be likely made an @ArquillianResource via custom provider. It would be useful if it can be run before @Deployment method or at least available in that method because some examples would require for example creating a DataSource before a war can be deployed.

This is crucial so test can prepare required environment.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 04:50:24 2011
From: jira-events at lists.jboss.org (winton xu (JIRA))
Date: Tue, 19 Jul 2011 04:50:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3146) timer rule cannot
 work fine,
 if the method 'ksession.fireAllRules()' is called before we reload
 KnowlegeSession.
Message-ID: <1706890422.62107.1311065424144.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

timer rule cannot work fine, if the method 'ksession.fireAllRules()' is called before we reload KnowlegeSession.
----------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-3146
                 URL: https://issues.jboss.org/browse/JBRULES-3146
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.2.0.Final
            Reporter: winton xu
            Assignee: Mark Proctor
            Priority: Critical


we can reproduce it by following steps.
1. create a knowledge session. and call the method 'fireAllRules()'
2. reload knowledge session.
3. crate and build a timer rule.
4. fire the timer rule.
[Actual Result]
the timer rule cannot work fine.

[Expected Result]
the timer rule can work fine.

(please check the attachement 'TimerAndCalendarTest.java.txt')

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 04:53:23 2011
From: jira-events at lists.jboss.org (winton xu (JIRA))
Date: Tue, 19 Jul 2011 04:53:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-3146) timer rule cannot
 work fine,
 if the method 'ksession.fireAllRules()' is called before we reload
 KnowlegeSession.
In-Reply-To: <1706890422.62107.1311065424144.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1979834809.62112.1311065603651.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

winton xu updated JBRULES-3146:
-------------------------------

    Attachment: TimerAndCalendarTest.java.txt


> timer rule cannot work fine, if the method 'ksession.fireAllRules()' is called before we reload KnowlegeSession.
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3146
>                 URL: https://issues.jboss.org/browse/JBRULES-3146
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.2.0.Final
>            Reporter: winton xu
>            Assignee: Mark Proctor
>            Priority: Critical
>         Attachments: TimerAndCalendarTest.java.txt
>
>
> we can reproduce it by following steps.
> 1. create a knowledge session. and call the method 'fireAllRules()'
> 2. reload knowledge session.
> 3. crate and build a timer rule.
> 4. fire the timer rule.
> [Actual Result]
> the timer rule cannot work fine.
> [Expected Result]
> the timer rule can work fine.
> (please check the attachement 'TimerAndCalendarTest.java.txt')

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 05:23:24 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 05:23:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1782) on cluster
 hiccup jbossmessaging dies
In-Reply-To: <57052573.1263200910802.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1144475080.62131.1311067404178.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao commented on JBMESSAGING-1782:
-------------------------------------------

The problem should be solved with JBMESSAGING-1842.

https://issues.jboss.org/browse/JBMESSAGING-1842

It introduced a new mbean MessagingClusterHealthMBean as well as some new attributes like KeepOldFailoverModel. It enhances jbm in such a way that when a node is 'isolated' but not dead, the failover will not happen. When the node is back the cluster is resumed. If the node is really dead, the failover will eventually happen.

Howard


> on cluster hiccup jbossmessaging dies
> -------------------------------------
>
>                 Key: JBMESSAGING-1782
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1782
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.3.GA, 1.4.6.GA
>         Environment: jboss 5.1
> jboss groups 2.6.13 GA
>            Reporter: Armin Haaf
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.8.SP2
>
>         Attachments: ejbtest.tgz
>
>
> sometimes we have a problem with our cluster loosing  a socket connection. Groups come up again, but messaging dies and  is no longer usable on this node.
> Node 1 gots suspected by node 2 (i'm not sure why). Node 1 gets removed from the cluster and trys to reconnect. Reconnect seems to work, but messaging is now dead
> output from node1:
> 2010-01-11 04:24:17,070 ERROR [org.jgroups.blocks.ConnectionTable] [T:169] failed sending data to 10.199.12.135:7900: java.net.SocketException: Broken pipe
> 2010-01-11 04:24:17,072 WARN  [org.jgroups.protocols.FD] [T:48734] I was suspected by 10.199.12.135:32792; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
> 2010-01-11 04:24:17,072 WARN  [org.jgroups.protocols.FD] [T:48717] I was suspected by 10.199.12.135:32792; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
> 2010-01-11 04:24:17,073 WARN  [org.jgroups.protocols.FD] [T:48720] I was suspected by 10.199.12.135:32792; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
> 2010-01-11 04:24:17,073 WARN  [org.jgroups.protocols.pbcast.GMS] [T:67] I (10.199.12.134:32797) am not a member of view [10.199.12.135:32792|12] [10.199.12.135:32792], shunning myself
> and leaving the group (prev_members are [10.199.12.135:32792, 10.199.12.134:32797], current view is [10.199.12.135:32792|11] [10.199.12.135:32792, 10.199.12.134:32797])
> 2010-01-11 04:24:17,073 WARN  [org.jgroups.protocols.pbcast.GMS] [T:48721] I (10.199.12.134:32797) am not a member of view [10.199.12.135:32792|10] [10.199.12.135:32792], shunning myse
> lf and leaving the group (prev_members are [10.199.12.135:32792, 10.199.12.134:32797], current view is [10.199.12.135:32792|9] [10.199.12.135:32792, 10.199.12.134:32797])
> 2010-01-11 04:24:17,074 WARN  [org.jgroups.protocols.pbcast.GMS] [T:48719] I (10.199.12.134:32797) am not a member of view [10.199.12.135:32792|12] [10.199.12.135:32792], shunning myse
> lf and leaving the group (prev_members are [10.199.12.135:32792, 10.199.12.134:32797], current view is [10.199.12.135:32792|11] [10.199.12.135:32792, 10.199.12.134:32797])
> 2010-01-11 04:24:17,075 ERROR [org.jgroups.protocols.UNICAST] [T:48718] 10.199.12.134:32797: sender window for 10.199.12.135:32792 not found
> 2010-01-11 04:24:17,585 INFO  [STDOUT] [T:48741]
> ---------------------------------------------------------
> GMS: address is 10.199.12.134:32799 (cluster=lisa2000)
> ---------------------------------------------------------
> 2010-01-11 04:24:17,591 INFO  [org.jboss.ha.framework.interfaces.HAPartition.lisa2000] [T:48741] New cluster view for partition lisa2000: 11 ([10.199.12.135:1099, 10.199.12.134:1099] d
> elta: 0)
> 2010-01-11 04:24:17,593 INFO  [STDOUT] [T:48742]
> ---------------------------------------------------------
> GMS: address is 10.199.12.134:32799 (cluster=MessagingPostOffice-CTRL)
> ---------------------------------------------------------
> 2010-01-11 04:24:17,594 INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:101] I am (10.199.12.134:1099) received membershipChanged event:
> 2010-01-11 04:24:17,594 INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:101] Dead members: 0 ([])
> 2010-01-11 04:24:17,594 INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:101] New Members : 0 ([])
> 2010-01-11 04:24:17,594 INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:101] All Members : 2 ([10.199.12.135:1099, 10.199.12.134:1099])
> 2010-01-11 04:24:17,601 INFO  [STDOUT] [T:48740]
> ---------------------------------------------------------
> GMS: address is 10.199.12.134:32799 (cluster=lisa2000-HAPartitionCache)
> ---------------------------------------------------------
> 2010-01-11 04:24:17,601 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:48742] org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 429c429c g
> ot new view [10.199.12.135:32792|13] [10.199.12.135:32792, 10.199.12.134:32799], old view is [10.199.12.135:32792|11] [10.199.12.135:32792, 10.199.12.134:32797]
> 2010-01-11 04:24:17,601 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:48742] I am (10.199.12.134:32799)
> 2010-01-11 04:24:17,609 INFO  [org.jboss.cache.RPCManagerImpl] [T:48740] Received new cluster view: [10.199.12.135:32792|13] [10.199.12.135:32792, 10.199.12.134:32799]
> 2010-01-11 04:24:17,617 INFO  [org.jboss.cache.statetransfer.LegacyStateTransferIntegrator] [T:48753] Using version 4096
> 2010-01-11 04:24:19,686 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:48742] Dead members: 1 ([10.199.12.134:32797])
> 2010-01-11 04:24:19,686 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:48742] New Members : 1 ([10.199.12.134:32799])
> 2010-01-11 04:24:19,686 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:48742] All Members : 2 ([10.199.12.135:32792, 10.199.12.134:32799])
> 2010-01-11 04:24:25,437 INFO  [lisa.logistics.core.ejb.CommandExecutionBean] [T:782] Execute of ping takes 10 ms.
> 2010-01-11 04:24:28,705 ERROR [org.jboss.messaging.util.ExceptionUtil] [T:194] ConnectionEndpoint[l26-sy0xoa4g-1-qtygu64g-qp6dlm-q3cj5a] createSessionDelegate [t26-d91xoa4g-1-qtygu64g-
> qp6dlm-q3cj5a]
> java.lang.IllegalStateException: Cannot find binding for queue DLQ
>         at org.jboss.jms.server.ServerPeer.getDefaultDLQInstance(ServerPeer.java:1254)
>         at org.jboss.jms.server.endpoint.ServerSessionEndpoint.<init>(ServerSessionEndpoint.java:228)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:249)
>         at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$createSessionDelegate$aop(ConnectionAdvised.java:75)
>         at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$createSessionDelegate_6052335267724906805.invokeTarget(ConnectionAdvised$createSessionDelegate_6052335267724906805.ja
> va)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
>         at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.createSessionDelegate(ConnectionAdvised.java)
>         at org.jboss.jms.wireformat.ConnectionCreateSessionDelegateRequest.serverInvoke(ConnectionCreateSessionDelegateRequest.java:87)
>         at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:143)
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
>         at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
>         at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
>         at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
>         at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> output from node 2:
> 2010-01-11 04:24:15,618 INFO  [org.jboss.ha.framework.interfaces.HAPartition.lifecycle.lisa2000] [T:46047] Suspected member: 10.199.12.134:32797
> 2010-01-11 04:24:15,680 INFO  [org.jboss.ha.framework.interfaces.HAPartition.lifecycle.lisa2000] [T:89] New cluster view for partition lisa2000 (id: 10, delta: -1) : [10.199.1
> 2.135:1099]
> 2010-01-11 04:24:15,681 INFO  [org.jboss.cache.RPCManagerImpl] [T:89] Received new cluster view: [10.199.12.135:32792|12] [10.199.12.135:32792]
> 2010-01-11 04:24:15,682 INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:106] I am (10.199.12.135:1099) received membershipChanged event:
> 2010-01-11 04:24:15,682 INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:106] Dead members: 1 ([10.199.12.134:1099])
> 2010-01-11 04:24:15,682 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:108] org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 443
> 24432 got new view [10.199.12.135:32792|12] [10.199.12.135:32792], old view is [10.199.12.135:32792|11] [10.199.12.135:32792, 10.199.12.134:32797]
> 2010-01-11 04:24:15,682 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:108] I am (10.199.12.135:32792)
> 2010-01-11 04:24:15,683 ERROR [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:108] Caught Exception in MembershipListener
> java.lang.IllegalStateException: org.jboss.messaging.core.impl.postoffice.MessagingPostOffice at 2b4e2b4e cannot find node ID for address 10.199.12.134:32797
>         at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.nodesLeft(MessagingPostOffice.java:942)
>         at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener.viewAccepted(GroupMember.java:508)
>         at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUpEvent(MessageDispatcher.java:733)
>         at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:776)
>         at org.jgroups.JChannel.up(JChannel.java:1336)
>         at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:454)
>         at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:435)
>         at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:153)
>         at org.jgroups.protocols.FRAG2.up(FRAG2.java:188)
>         at org.jgroups.protocols.FC.up(FC.java:493)
>         at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:543)
>         at org.jgroups.protocols.pbcast.CoordGmsImpl.handleViewChange(CoordGmsImpl.java:463)
>         at org.jgroups.protocols.pbcast.GMS.up(GMS.java:749)
>         at org.jgroups.protocols.VIEW_SYNC.up(VIEW_SYNC.java:192)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:233)
>         at org.jgroups.protocols.UNICAST.up(UNICAST.java:328)
>         at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:895)
>         at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:708)
>         at org.jgroups.protocols.BARRIER.up(BARRIER.java:136)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:167)
>         at org.jgroups.protocols.FD.up(FD.java:284)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:307)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:144)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:262)
>         at org.jgroups.protocols.PING.up(PING.java:273)
>         at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2315)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:1249)
>         at org.jgroups.protocols.TP.access$100(TP.java:49)
>         at org.jgroups.protocols.TP$1.run(TP.java:1176)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:736)
> 2010-01-11 04:24:15,682 INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:106] New Members : 0 ([])
> 2010-01-11 04:24:15,683 INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:106] All Members : 1 ([10.199.12.135:1099])
> 2010-01-11 04:24:17,033 WARN  [org.jgroups.protocols.pbcast.NAKACK] [T:46042] 10.199.12.135:32792] discarded message from non-member 10.199.12.134:32797, my view is [10.199.12
> .135:32792|12] [10.199.12.135:32792]
> 2010-01-11 04:24:17,033 WARN  [org.jgroups.protocols.pbcast.NAKACK] [T:46041] 10.199.12.135:32792] discarded message from non-member 10.199.12.134:32797, my view is [10.199.12
> .135:32792|10] [10.199.12.135:32792]
> 2010-01-11 04:24:17,069 WARN  [org.jgroups.protocols.pbcast.NAKACK] [T:46041] 10.199.12.135:32792] discarded message from non-member 10.199.12.134:32797, my view is [10.199.12
> .135:32792|10] [10.199.12.135:32792]
> 2010-01-11 04:24:17,072 WARN  [org.jgroups.protocols.pbcast.NAKACK] [T:45905] 10.199.12.135:7900] discarded message from non-member 10.199.12.134:7900, my view is [10.199.12.1
> 35:7900|10] [10.199.12.135:7900]
> 2010-01-11 04:24:17,589 INFO  [org.jboss.ha.framework.interfaces.HAPartition.lifecycle.lisa2000] [T:103] New cluster view for partition lisa2000 (id: 11, delta: 1) : [10.199.1
> 2.135:1099, 10.199.12.134:1099]
> 2010-01-11 04:24:17,589 INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:106] I am (10.199.12.135:1099) received membershipChanged event:
> 2010-01-11 04:24:17,589 INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:106] Dead members: 0 ([])
> 2010-01-11 04:24:17,589 INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:106] New Members : 1 ([10.199.12.134:1099])
> 2010-01-11 04:24:17,589 INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:106] All Members : 2 ([10.199.12.135:1099, 10.199.12.134:1099])
> 2010-01-11 04:24:17,597 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:113] org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 443
> 24432 got new view [10.199.12.135:32792|13] [10.199.12.135:32792, 10.199.12.134:32799], old view is [10.199.12.135:32792|12] [10.199.12.135:32792]
> 2010-01-11 04:24:17,597 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:113] I am (10.199.12.135:32792)
> 2010-01-11 04:24:17,597 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:113] New Members : 1 ([10.199.12.134:32799])
> 2010-01-11 04:24:17,597 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:113] All Members : 2 ([10.199.12.135:32792, 10.199.12.134:32799])
> 2010-01-11 04:24:17,607 INFO  [org.jboss.cache.RPCManagerImpl] [T:99] Received new cluster view: [10.199.12.135:32792|13] [10.199.12.135:32792, 10.199.12.134:32799]
> 2010-01-11 04:24:19,609 WARN  [org.jgroups.protocols.pbcast.GMS] [T:46052] 10.199.12.135:32792 failed to collect all ACKs (1) for unicasted view [10.199.12.135:32792|13] [10.1
> 99.12.135:32792, 10.199.12.134:32799] after 2000ms, missing ACKs from [10.199.12.134:32799], local_addr=10.199.12.135:32792
> 2010-01-11 04:24:19,611 ERROR [org.jboss.messaging.core.impl.postoffice.UnbindRequest] [T:875] Failed to remove binding
> java.lang.IllegalStateException: Don't know about node id: 1
>         at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.removeBindingFromCluster(MessagingPostOffice.java:1079)
>         at org.jboss.messaging.core.impl.postoffice.UnbindRequest.execute(UnbindRequest.java:61)
>         at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlRequestHandler.handle(GroupMember.java:622)
>         at org.jgroups.blocks.MessageDispatcher.handle(MessageDispatcher.java:616)
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:637)
>         at org.jgroups.blocks.RequestCorrelator$Request.run(RequestCorrelator.java:944)
>         at org.jgroups.util.ReusableThread.run(ReusableThread.java:220)
>         at java.lang.Thread.run(Thread.java:736)
> 2010-01-11 04:24:19,611 ERROR [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:875] Caught Exception in RequestHandler
> java.lang.Exception: Failed to remove binding
>         at org.jboss.messaging.core.impl.postoffice.UnbindRequest.execute(UnbindRequest.java:67)
>         at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlRequestHandler.handle(GroupMember.java:622)
>         at org.jgroups.blocks.MessageDispatcher.handle(MessageDispatcher.java:616)
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:637)
>         at org.jgroups.blocks.RequestCorrelator$Request.run(RequestCorrelator.java:944)
>         at org.jgroups.util.ReusableThread.run(ReusableThread.java:220)
>         at java.lang.Thread.run(Thread.java:736)
> Caused by:
> java.lang.IllegalStateException: Don't know about node id: 1
>         at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.removeBindingFromCluster(MessagingPostOffice.java:1079)
>         at org.jboss.messaging.core.impl.postoffice.UnbindRequest.execute(UnbindRequest.java:61)
>         ... 6 more
> 2010-01-11 04:24:19,611 ERROR [org.jgroups.blocks.RequestCorrelator] [T:875] error invoking method
> java.lang.IllegalStateException: Failed to remove binding
>         at org.jboss.messaging.core.impl.postoffice.UnbindRequest.execute(UnbindRequest.java:67)
>         at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlRequestHandler.handle(GroupMember.java:622)
>         at org.jgroups.blocks.MessageDispatcher.handle(MessageDispatcher.java:616)
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:637)
>         at org.jgroups.blocks.RequestCorrelator$Request.run(RequestCorrelator.java:944)
>         at org.jgroups.util.ReusableThread.run(ReusableThread.java:220)
>         at java.lang.Thread.run(Thread.java:736)
> 2010-01-11 04:24:19,622 ERROR [org.jboss.messaging.core.impl.postoffice.UnbindRequest] [T:875] Failed to remove binding
> java.lang.IllegalStateException: Don't know about node id: 1
>         at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.removeBindingFromCluster(MessagingPostOffice.java:1079)
>         at org.jboss.messaging.core.impl.postoffice.UnbindRequest.execute(UnbindRequest.java:61)
>         at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlRequestHandler.handle(GroupMember.java:622)
>         at org.jgroups.blocks.MessageDispatcher.handle(MessageDispatcher.java:616)
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:637)
>         at org.jgroups.blocks.RequestCorrelator$Request.run(RequestCorrelator.java:944)
>         at org.jgroups.util.ReusableThread.run(ReusableThread.java:220)
>         at java.lang.Thread.run(Thread.java:736)
> 2010-01-11 04:24:19,623 ERROR [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:875] Caught Exception in RequestHandler
> java.lang.Exception: Failed to remove binding
>         at org.jboss.messaging.core.impl.postoffice.UnbindRequest.execute(UnbindRequest.java:67)
>         at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlRequestHandler.handle(GroupMember.java:622)
>         at org.jgroups.blocks.MessageDispatcher.handle(MessageDispatcher.java:616)
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:637)
>         at org.jgroups.blocks.RequestCorrelator$Request.run(RequestCorrelator.java:944)
>         at org.jgroups.util.ReusableThread.run(ReusableThread.java:220)
>         at java.lang.Thread.run(Thread.java:736)
> Caused by:
> java.lang.IllegalStateException: Don't know about node id: 1
>         at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.removeBindingFromCluster(MessagingPostOffice.java:1079)
>         at org.jboss.messaging.core.impl.postoffice.UnbindRequest.execute(UnbindRequest.java:61)
>         ... 6 more
> 2010-01-11 04:24:19,623 ERROR [org.jgroups.blocks.RequestCorrelator] [T:875] error invoking method
> java.lang.IllegalStateException: Failed to remove binding
>         at org.jboss.messaging.core.impl.postoffice.UnbindRequest.execute(UnbindRequest.java:67)
>         at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlRequestHandler.handle(GroupMember.java:622)
>         at org.jgroups.blocks.MessageDispatcher.handle(MessageDispatcher.java:616)
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:637)
>         at org.jgroups.blocks.RequestCorrelator$Request.run(RequestCorrelator.java:944)
>         at org.jgroups.util.ReusableThread.run(ReusableThread.java:220)
>         at java.lang.Thread.run(Thread.java:736)
> 2010-01-11 04:24:23,881 WARN  [org.jgroups.protocols.pbcast.NAKACK] [T:46065] 10.199.12.135:7900] discarded message from non-member 10.199.12.134:7900, my view is [10.199.12.1
> 35:7900|10] [10.199.12.135:7900]
> 2010-01-11 04:24:32,813 WARN  [org.jgroups.protocols.pbcast.NAKACK] [T:46065] 10.199.12.135:7900] discarded message from non-member 10.199.12.134:7900, my view is [10.199.12.1
> 35:7900|10] [10.199.12.135:7900]
> 2010-01-11 04:24:33,501 WARN  [org.jgroups.protocols.pbcast.NAKACK] [T:46065] 10.199.12.135:7900] discarded message from non-member 10.199.12.134:7900, my view is [10.199.12.1
> 35:7900|10] [10.199.12.135:7900]
> 2010-01-11 04:24:45,201 WARN  [org.jgroups.protocols.pbcast.NAKACK] [T:46069] 10.199.12.135:7900] discarded message from non-member 10.199.12.134:7900, my view is [10.199.12.1
> 35:7900|10] [10.199.12.135:7900]
> 2010-01-11 04:24:53,645 ERROR [org.jgroups.blocks.ConnectionTable] [T:171] failed sending data to 10.199.12.134:7900: java.net.SocketException: Socket closed

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 05:37:23 2011
From: jira-events at lists.jboss.org (Aslak Knutsen (JIRA))
Date: Tue, 19 Jul 2011 05:37:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1318)
 CommonContainerConfiguration should contain managementAddress
In-Reply-To: <997120400.60461.1310998703826.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <347506851.62181.1311068243722.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Aslak Knutsen commented on AS7-1318:
------------------------------------

httpPort and jmxPort should be removed. Management ip /port is enough, we can figure out httpPort/jmxPort/ip etc using the Mgm APIs.

> CommonContainerConfiguration should contain managementAddress
> -------------------------------------------------------------
>
>                 Key: AS7-1318
>                 URL: https://issues.jboss.org/browse/AS7-1318
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 7.0.0.Final
>            Reporter: Rostislav Svoboda
>            Assignee: Andrew Rubinger
>             Fix For: 7.1.0.Alpha1
>
>
> CommonContainerConfiguration (org.jboss.as.arquillian.container) should contain managementAddress.
> AS7 can be configured to use different IP addresses for management and public interface. 
> This could be problem for testing in remote mode.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 05:41:23 2011
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Tue, 19 Jul 2011 05:41:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (AS7-1338) Remote JNDI support for
	AS7
Message-ID: <1781186591.62206.1311068483656.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Richard Opalka moved JBWS-3234 to AS7-1338:
-------------------------------------------

     Project: Application Server 7  (was: JBoss Web Services)
         Key: AS7-1338  (was: JBWS-3234)
    Workflow: GIT Pull Request workflow   (was: jira)
    Security:     (was: Public)


> Remote JNDI support for AS7
> ---------------------------
>
>                 Key: AS7-1338
>                 URL: https://issues.jboss.org/browse/AS7-1338
>             Project: Application Server 7
>          Issue Type: Task
>            Reporter: Richard Opalka
>            Priority: Blocker
>
> <opalka>  wolfc, dmlloyd I'm not able to connect to JNDI on AS7. in the AS7 config I see it should be running on 1099, but I'm getting http://fpaste.org/wgy8/ :(
> <opalka>  wolfc, dmlloyd in the config I see the following ports defined
> <opalka>  ---
> <opalka>  <socket-binding name="jndi" port="1099"/>
> <opalka>  <socket-binding name="jmx-connector-registry" port="1090"/>
> <opalka>  <socket-binding name="jmx-connector-server" port="1091"/>
> <opalka>  ---
> <dmlloyd> we don't do JNDI over RMI anymore
> <dmlloyd> that listing is an error
> <opalka>  dmlloyd, So we're not able to do JNDI lookups to AS7 anymore and don't plan to?
> <opalka>  dmlloyd, or we'll be doing JNDI over different binary protocol?
> <dmlloyd> no, we will be able to, it'll just work somewhat differently
> <opalka>  dmlloyd, ok, I'm excluding the tests then ...
> <opalka>  dmlloyd, Is there a JIRA covering this issue so I can use it in my excludes comment?
> <dmlloyd> not that I'm aware of, it's just an outstanding task
> <dmlloyd> remote invocation is not planned to be covered in next months' beta release
> <opalka>  dmlloyd, ok, thx for info ;)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 05:43:28 2011
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Tue, 19 Jul 2011 05:43:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1338) Remote JNDI support
	for AS7
Message-ID: <77242885.62211.1311068608548.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Richard Opalka updated AS7-1338:
--------------------------------

    Fix Version/s: 7.1.0.Alpha1
      Component/s: Naming


> Remote JNDI support for AS7
> ---------------------------
>
>                 Key: AS7-1338
>                 URL: https://issues.jboss.org/browse/AS7-1338
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Naming
>            Reporter: Richard Opalka
>            Priority: Blocker
>             Fix For: 7.1.0.Alpha1
>
>
> <opalka>  wolfc, dmlloyd I'm not able to connect to JNDI on AS7. in the AS7 config I see it should be running on 1099, but I'm getting http://fpaste.org/wgy8/ :(
> <opalka>  wolfc, dmlloyd in the config I see the following ports defined
> <opalka>  ---
> <opalka>  <socket-binding name="jndi" port="1099"/>
> <opalka>  <socket-binding name="jmx-connector-registry" port="1090"/>
> <opalka>  <socket-binding name="jmx-connector-server" port="1091"/>
> <opalka>  ---
> <dmlloyd> we don't do JNDI over RMI anymore
> <dmlloyd> that listing is an error
> <opalka>  dmlloyd, So we're not able to do JNDI lookups to AS7 anymore and don't plan to?
> <opalka>  dmlloyd, or we'll be doing JNDI over different binary protocol?
> <dmlloyd> no, we will be able to, it'll just work somewhat differently
> <opalka>  dmlloyd, ok, I'm excluding the tests then ...
> <opalka>  dmlloyd, Is there a JIRA covering this issue so I can use it in my excludes comment?
> <dmlloyd> not that I'm aware of, it's just an outstanding task
> <dmlloyd> remote invocation is not planned to be covered in next months' beta release
> <opalka>  dmlloyd, ok, thx for info ;)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 05:52:23 2011
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 19 Jul 2011 05:52:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1346) Update documentation
Message-ID: <1720745363.62235.1311069143787.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Update documentation
--------------------

                 Key: JGRP-1346
                 URL: https://issues.jboss.org/browse/JGRP-1346
             Project: JGroups
          Issue Type: Sub-task
            Reporter: Bela Ban
            Assignee: Bela Ban


javadocs, manual, tutorial

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 05:54:24 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 19 Jul 2011 05:54:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1182) Incorrect security
 domain selected for web application.
In-Reply-To: <320201656.33784.1309788924180.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <320154573.62252.1311069264196.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse commented on AS7-1182:
---------------------------------------

Jeurgen, is the <security-domain> in the jboss.xml and jboss-web.xml still working?

Your previous assessment "It sounds like <security-domain> in jboss-app.xml is ignored." was correct, I am following up with on that one as it does seem the jboss-app.xml is only partially supported.

> Incorrect security domain selected for web application.
> -------------------------------------------------------
>
>                 Key: AS7-1182
>                 URL: https://issues.jboss.org/browse/AS7-1182
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: Darran Lofthouse
>         Attachments: test.ear.zip, testcase-src.zip
>
>
> I want to migrate from JBossAS 6 to 7.0.0.CR1. In standalone.xml I declare the following security domain, but get the stacktrace (see below) looking for UsersRolesLoginModule instead of DatabaseServerLoginModule.
> Security domain in standalone.xml:
>    <security-domain name="swe2" cache-type="default">
>       <authentication>
>          <login-module code="Database" flag="required">
>             <module-option name="dsJndiName" value="java:/swe2DS"/>
>             <module-option name="unauthenticatedIdentity" value="gast"/>
>             <module-option name="principalsQuery" value="SELECT password FROM kunde WHERE username=?"/>
>             <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM swe2_role r INNER JOIN kunde k ON r.kunde_fk = k.k_id WHERE k.username=?"/>
>             <module-option name="hashAlgorithm" value="SHA-1"/>
>             <module-option name="hashEncoding" value="base64"/>
>          </login-module>
>       </authentication>
>    </security-domain>
> Stacktrace regarding UsersRolesLoginModule (instead of DatabaseServerLoginModule):
> 16:03:58,528 ERROR [org.jboss.security.auth.spi.UsersRolesLoginModule] (http--127.0.0.1-8080-2) Failed to load users/passwords/role files: java.io.IOException: No properties file: users.properties or defaults: defaultUsers.properties found
> 	at org.jboss.security.auth.spi.Util.loadProperties(Util.java:227) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:188) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:202) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:129) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	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 javax.security.auth.login.LoginContext.invoke(LoginContext.java:756) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683) [:1.6.0_26]
> 	at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:579) [:1.6.0_26]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:411) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:154) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:127) [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:180) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:446) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 06:16:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 19 Jul 2011 06:16:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1210) Messaging subsystem
 binds JMS destinations to java:
In-Reply-To: <1452571861.37545.1309963283664.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <423860331.62302.1311070583786.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai reassigned AS7-1210:
---------------------------------

    Assignee: jaikiran pai


> Messaging subsystem binds JMS destinations to java:
> ---------------------------------------------------
>
>                 Key: AS7-1210
>                 URL: https://issues.jboss.org/browse/AS7-1210
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 7.0.0.CR1, 7.0.0.Final
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> As per the discussion in this mail thread http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/002890.html:
> {quote}
> 1) Unqualified relative names like "DefaultDS" or "jdbc/DefaultDS" 
> should be qualified relative to "java:comp/env", "java:module/env", or 
> "java:jboss/env", depending on the context.
> {quote}
> So in case of JMS destinations configured in the standalone.xml/domain.xml, JNDI entries like these:
> {code:xml}
>            <jms-destinations>
>               <jms-queue name="testQueue">
>                  <entry name="queue/test"/>
>               </jms-queue>
>               <jms-topic name="testTopic">
>                  <entry name="topic/test"/>
>               </jms-topic>
>            </jms-destinations>
> {code}
> should bind under java:jboss/ namespace. 
> Instead, currently the org.jboss.as.messaging.jms.AS7BindingRegistry binds it to java: namespace.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 06:16:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 19 Jul 2011 06:16:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1210) Messaging subsystem
 binds JMS destinations to java:
In-Reply-To: <1452571861.37545.1309963283664.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1622545414.62304.1311070583848.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai updated AS7-1210:
------------------------------

    Affects Version/s: 7.0.0.Final
      Forum Reference: http://community.jboss.org/message/613662#613662  (was: http://community.jboss.org/message/613662#613662)


> Messaging subsystem binds JMS destinations to java:
> ---------------------------------------------------
>
>                 Key: AS7-1210
>                 URL: https://issues.jboss.org/browse/AS7-1210
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 7.0.0.CR1, 7.0.0.Final
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> As per the discussion in this mail thread http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/002890.html:
> {quote}
> 1) Unqualified relative names like "DefaultDS" or "jdbc/DefaultDS" 
> should be qualified relative to "java:comp/env", "java:module/env", or 
> "java:jboss/env", depending on the context.
> {quote}
> So in case of JMS destinations configured in the standalone.xml/domain.xml, JNDI entries like these:
> {code:xml}
>            <jms-destinations>
>               <jms-queue name="testQueue">
>                  <entry name="queue/test"/>
>               </jms-queue>
>               <jms-topic name="testTopic">
>                  <entry name="topic/test"/>
>               </jms-topic>
>            </jms-destinations>
> {code}
> should bind under java:jboss/ namespace. 
> Instead, currently the org.jboss.as.messaging.jms.AS7BindingRegistry binds it to java: namespace.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 06:20:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 19 Jul 2011 06:20:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1210) Messaging subsystem
 binds JMS destinations to java:
In-Reply-To: <1452571861.37545.1309963283664.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1796423140.62340.1311070824928.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on AS7-1210:
-----------------------------------

Even the ConnectionFactory binding ends up in the wrong place:

{code:xml}
<connection-factory name="InVmConnectionFactory">
                    <connectors>
                        <connector-ref connector-name="in-vm"/>
                    </connectors>
                    <entries>
                        <entry name="java:/ConnectionFactory"/>
                    </entries>
                </connection-factory>
{code}

Related http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/003216.html
 

> Messaging subsystem binds JMS destinations to java:
> ---------------------------------------------------
>
>                 Key: AS7-1210
>                 URL: https://issues.jboss.org/browse/AS7-1210
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 7.0.0.CR1, 7.0.0.Final
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> As per the discussion in this mail thread http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/002890.html:
> {quote}
> 1) Unqualified relative names like "DefaultDS" or "jdbc/DefaultDS" 
> should be qualified relative to "java:comp/env", "java:module/env", or 
> "java:jboss/env", depending on the context.
> {quote}
> So in case of JMS destinations configured in the standalone.xml/domain.xml, JNDI entries like these:
> {code:xml}
>            <jms-destinations>
>               <jms-queue name="testQueue">
>                  <entry name="queue/test"/>
>               </jms-queue>
>               <jms-topic name="testTopic">
>                  <entry name="topic/test"/>
>               </jms-topic>
>            </jms-destinations>
> {code}
> should bind under java:jboss/ namespace. 
> Instead, currently the org.jboss.as.messaging.jms.AS7BindingRegistry binds it to java: namespace.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 06:40:23 2011
From: jira-events at lists.jboss.org (Shaun Appleton (JIRA))
Date: Tue, 19 Jul 2011 06:40:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-2262) When throwing an
 application exception in a method that is annotated with NOT_SUPPORTED it
 should not wrap the application Exception.
Message-ID: <546050987.62390.1311072023666.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

When throwing an application exception in a method that is annotated with NOT_SUPPORTED it should not wrap the application Exception.
-------------------------------------------------------------------------------------------------------------------------------------

                 Key: EJBTHREE-2262
                 URL: https://issues.jboss.org/browse/EJBTHREE-2262
             Project: EJB 3.0
          Issue Type: Bug
            Reporter: Shaun Appleton


When throwing an application exception in a method that is annotated with NOT_SUPPORTED it should not wrap the application Exception.
What currently happen is that it is wrapped in an EJBException instead of being thrown un-wrapped.

See Table 14 p361. of jsr-220 spec

This has been tested on EAP 5.1.0



--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 06:46:23 2011
From: jira-events at lists.jboss.org (Shaun Appleton (JIRA))
Date: Tue, 19 Jul 2011 06:46:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-2262) When throwing an
 application exception in a method that is annotated with NOT_SUPPORTED it
 should not wrap the application Exception.
In-Reply-To: <546050987.62390.1311072023666.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <406377205.62393.1311072383771.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Shaun Appleton updated EJBTHREE-2262:
-------------------------------------

    Attachment: stateless_00500318.zip


> When throwing an application exception in a method that is annotated with NOT_SUPPORTED it should not wrap the application Exception.
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-2262
>                 URL: https://issues.jboss.org/browse/EJBTHREE-2262
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Shaun Appleton
>         Attachments: stateless_00500318.zip
>
>
> When throwing an application exception in a method that is annotated with NOT_SUPPORTED it should not wrap the application Exception.
> What currently happen is that it is wrapped in an EJBException instead of being thrown un-wrapped.
> See Table 14 p361. of jsr-220 spec
> This has been tested on EAP 5.1.0

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 06:57:23 2011
From: jira-events at lists.jboss.org (Shaun Appleton (JIRA))
Date: Tue, 19 Jul 2011 06:57:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-2262) When throwing an
 application exception in a method that is annotated with NOT_SUPPORTED it
 should not wrap the application Exception.
In-Reply-To: <546050987.62390.1311072023666.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1324469406.62415.1311073043687.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Shaun Appleton updated EJBTHREE-2262:
-------------------------------------

    Steps to Reproduce: 
run attached code (based on the EJB3 tutorial)
set JBOSS_HOME first
ant
run up eap
ant run
observe ERROR [STDERR] javax.ejb.EJBException: org.jboss.tutorial.stateless.bean.MyException: Alert! Alert! in EAP log


  was:run attached code (based on the EJB3 tutorial)



> When throwing an application exception in a method that is annotated with NOT_SUPPORTED it should not wrap the application Exception.
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-2262
>                 URL: https://issues.jboss.org/browse/EJBTHREE-2262
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Shaun Appleton
>         Attachments: stateless_00500318.zip
>
>
> When throwing an application exception in a method that is annotated with NOT_SUPPORTED it should not wrap the application Exception.
> What currently happen is that it is wrapped in an EJBException instead of being thrown un-wrapped.
> See Table 14 p361. of jsr-220 spec
> This has been tested on EAP 5.1.0

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 07:56:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 19 Jul 2011 07:56:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1339) Expose RA config
	properties in DMR
Message-ID: <639400179.62523.1311076583633.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Expose RA config properties in DMR
----------------------------------

                 Key: AS7-1339
                 URL: https://issues.jboss.org/browse/AS7-1339
             Project: Application Server 7
          Issue Type: Feature Request
          Components: JCA
            Reporter: Heiko Braun
            Assignee: Jesper Pedersen
             Fix For: 7.1.0.Beta1



The config attributes are not exposed:

<subsystem xmlns="urn:jboss:domain:resource-adapters:1.0">
	[...]         
	
         <config-property name="host">talk.google.com</config-property>
         <config-property name="port">5222</config-property>
  
	[...]
   </resource-adapters>



[standalone at localhost:9999 /] /subsystem=resource-adapters/resource-adapter=xmpp-ra.rar:read-resource
{
    "outcome" => "success",
    "result" => {
        "archive" => "xmpp-ra.rar",
        "background-validation" => undefined,
        "background-validation-minutes" => undefined,
        "blocking-timeout-wait-millis" => undefined,
        "connection-definitions" => [{
            "class-name" => "com/ramphastos/xmpp/jca/XmppManagedConnectionFactory",
            "jndi-name" => "java:/eis/ra-xmpp",
            "pool-name" => "XmppFactoryPool",
            "enabled" => true,
            "use-java-context" => true,
            "use-ccm" => true,
            "max-pool-size" => 100,
            "min-pool-size" => 10,
            "pool-prefill" => false,
            "pool-use-strict-min" => false,
            "flush-strategy" => "FAILING_CONNECTION_ONLY",
            "security-application" => true
        }],
        "idle-timeout-minutes" => undefined,
        "max-pool-size" => undefined,
        "min-pool-size" => undefined,
        "pool-prefill" => undefined,
        "pool-use-strict-min" => undefined,
        "transaction-support" => "NoTransaction",
        "use-fast-fail" => undefined
    }
}


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 07:58:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 19 Jul 2011 07:58:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1339) Expose RA config
	properties in DMR
In-Reply-To: <639400179.62523.1311076583633.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1742275936.62528.1311076703650.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun updated AS7-1339:
-----------------------------

    Description: 
{noformat}
The config attributes are not exposed:

<subsystem xmlns="urn:jboss:domain:resource-adapters:1.0">
	[...]         
	
         <config-property name="host">talk.google.com</config-property>
         <config-property name="port">5222</config-property>
  
	[...]
   </resource-adapters>



[standalone at localhost:9999 /] /subsystem=resource-adapters/resource-adapter=xmpp-ra.rar:read-resource
{
    "outcome" => "success",
    "result" => {
        "archive" => "xmpp-ra.rar",
        "background-validation" => undefined,
        "background-validation-minutes" => undefined,
        "blocking-timeout-wait-millis" => undefined,
        "connection-definitions" => [{
            "class-name" => "com/ramphastos/xmpp/jca/XmppManagedConnectionFactory",
            "jndi-name" => "java:/eis/ra-xmpp",
            "pool-name" => "XmppFactoryPool",
            "enabled" => true,
            "use-java-context" => true,
            "use-ccm" => true,
            "max-pool-size" => 100,
            "min-pool-size" => 10,
            "pool-prefill" => false,
            "pool-use-strict-min" => false,
            "flush-strategy" => "FAILING_CONNECTION_ONLY",
            "security-application" => true
        }],
        "idle-timeout-minutes" => undefined,
        "max-pool-size" => undefined,
        "min-pool-size" => undefined,
        "pool-prefill" => undefined,
        "pool-use-strict-min" => undefined,
        "transaction-support" => "NoTransaction",
        "use-fast-fail" => undefined
    }
}

{noformat}


  was:

The config attributes are not exposed:

<subsystem xmlns="urn:jboss:domain:resource-adapters:1.0">
	[...]         
	
         <config-property name="host">talk.google.com</config-property>
         <config-property name="port">5222</config-property>
  
	[...]
   </resource-adapters>



[standalone at localhost:9999 /] /subsystem=resource-adapters/resource-adapter=xmpp-ra.rar:read-resource
{
    "outcome" => "success",
    "result" => {
        "archive" => "xmpp-ra.rar",
        "background-validation" => undefined,
        "background-validation-minutes" => undefined,
        "blocking-timeout-wait-millis" => undefined,
        "connection-definitions" => [{
            "class-name" => "com/ramphastos/xmpp/jca/XmppManagedConnectionFactory",
            "jndi-name" => "java:/eis/ra-xmpp",
            "pool-name" => "XmppFactoryPool",
            "enabled" => true,
            "use-java-context" => true,
            "use-ccm" => true,
            "max-pool-size" => 100,
            "min-pool-size" => 10,
            "pool-prefill" => false,
            "pool-use-strict-min" => false,
            "flush-strategy" => "FAILING_CONNECTION_ONLY",
            "security-application" => true
        }],
        "idle-timeout-minutes" => undefined,
        "max-pool-size" => undefined,
        "min-pool-size" => undefined,
        "pool-prefill" => undefined,
        "pool-use-strict-min" => undefined,
        "transaction-support" => "NoTransaction",
        "use-fast-fail" => undefined
    }
}




> Expose RA config properties in DMR
> ----------------------------------
>
>                 Key: AS7-1339
>                 URL: https://issues.jboss.org/browse/AS7-1339
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jesper Pedersen
>             Fix For: 7.1.0.Beta1
>
>
> {noformat}
> The config attributes are not exposed:
> <subsystem xmlns="urn:jboss:domain:resource-adapters:1.0">
> 	[...]         
> 	
>          <config-property name="host">talk.google.com</config-property>
>          <config-property name="port">5222</config-property>
>   
> 	[...]
>    </resource-adapters>
> [standalone at localhost:9999 /] /subsystem=resource-adapters/resource-adapter=xmpp-ra.rar:read-resource
> {
>     "outcome" => "success",
>     "result" => {
>         "archive" => "xmpp-ra.rar",
>         "background-validation" => undefined,
>         "background-validation-minutes" => undefined,
>         "blocking-timeout-wait-millis" => undefined,
>         "connection-definitions" => [{
>             "class-name" => "com/ramphastos/xmpp/jca/XmppManagedConnectionFactory",
>             "jndi-name" => "java:/eis/ra-xmpp",
>             "pool-name" => "XmppFactoryPool",
>             "enabled" => true,
>             "use-java-context" => true,
>             "use-ccm" => true,
>             "max-pool-size" => 100,
>             "min-pool-size" => 10,
>             "pool-prefill" => false,
>             "pool-use-strict-min" => false,
>             "flush-strategy" => "FAILING_CONNECTION_ONLY",
>             "security-application" => true
>         }],
>         "idle-timeout-minutes" => undefined,
>         "max-pool-size" => undefined,
>         "min-pool-size" => undefined,
>         "pool-prefill" => undefined,
>         "pool-use-strict-min" => undefined,
>         "transaction-support" => "NoTransaction",
>         "use-fast-fail" => undefined
>     }
> }
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 08:07:24 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Tue, 19 Jul 2011 08:07:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1340) web subsystem /
 virtual-server has no description for "enable-welcome-root"
Message-ID: <937364577.62545.1311077244010.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

web subsystem / virtual-server has no description for         "enable-welcome-root"
-----------------------------------------------------------------------------------

                 Key: AS7-1340
                 URL: https://issues.jboss.org/browse/AS7-1340
             Project: Application Server 7
          Issue Type: Bug
          Components: Web
    Affects Versions: 7.0.0.Final
            Reporter: Heiko Rupp
            Assignee: Remy Maucherat


/subsystem=web/virtual-server=default-host:read-resource lists

        "enable-welcome-root" => true,

but this is not described with :read-resource-description

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 08:11:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 19 Jul 2011 08:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1282) Rar classes are not
 made available to deployments
In-Reply-To: <506537509.53413.1310642303654.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1855858131.62555.1311077483937.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf updated AS7-1282:
-------------------------------

    Workaround Description: 
Add an explicit dependency to the manifest.

Dependencies: org.hornetq.ra


> Rar classes are not made available to deployments
> -------------------------------------------------
>
>                 Key: AS7-1282
>                 URL: https://issues.jboss.org/browse/AS7-1282
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Carlo de Wolf
>            Assignee: Stefano Maestri
>            Priority: Critical
>             Fix For: 7.1.0.CR1
>
>
> The rar classes are not made available to a deployment.
> {noformat}
> java.lang.ClassNotFoundException: org.hornetq.ra.inflow.HornetQActivationSpec from [Module "deployment.ejb3mdb.jar:main" from Service Module Loader]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> {noformat}
> JCA 1.6 20.3 Class Loading Requirements
> {quote}
> If a standalone resource adapter is configured to deliver messages to a message-
> driven bean in an application, the standalone resource adapter must be made
> available to the application.
> {quote}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 08:40:28 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 19 Jul 2011 08:40:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1339) Expose RA config
 properties in DMR
In-Reply-To: <639400179.62523.1311076583633.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <790502794.62649.1311079228730.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen reassigned AS7-1339:
------------------------------------

    Assignee: Jeff Zhang  (was: Jesper Pedersen)


> Expose RA config properties in DMR
> ----------------------------------
>
>                 Key: AS7-1339
>                 URL: https://issues.jboss.org/browse/AS7-1339
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.Beta1
>
>
> {noformat}
> The config attributes are not exposed:
> <subsystem xmlns="urn:jboss:domain:resource-adapters:1.0">
> 	[...]         
> 	
>          <config-property name="host">talk.google.com</config-property>
>          <config-property name="port">5222</config-property>
>   
> 	[...]
>    </resource-adapters>
> [standalone at localhost:9999 /] /subsystem=resource-adapters/resource-adapter=xmpp-ra.rar:read-resource
> {
>     "outcome" => "success",
>     "result" => {
>         "archive" => "xmpp-ra.rar",
>         "background-validation" => undefined,
>         "background-validation-minutes" => undefined,
>         "blocking-timeout-wait-millis" => undefined,
>         "connection-definitions" => [{
>             "class-name" => "com/ramphastos/xmpp/jca/XmppManagedConnectionFactory",
>             "jndi-name" => "java:/eis/ra-xmpp",
>             "pool-name" => "XmppFactoryPool",
>             "enabled" => true,
>             "use-java-context" => true,
>             "use-ccm" => true,
>             "max-pool-size" => 100,
>             "min-pool-size" => 10,
>             "pool-prefill" => false,
>             "pool-use-strict-min" => false,
>             "flush-strategy" => "FAILING_CONNECTION_ONLY",
>             "security-application" => true
>         }],
>         "idle-timeout-minutes" => undefined,
>         "max-pool-size" => undefined,
>         "min-pool-size" => undefined,
>         "pool-prefill" => undefined,
>         "pool-use-strict-min" => undefined,
>         "transaction-support" => "NoTransaction",
>         "use-fast-fail" => undefined
>     }
> }
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 09:08:24 2011
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Tue, 19 Jul 2011 09:08:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-2992) Could not parse
 escaped characters
In-Reply-To: <1959743421.7947.1303804938478.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2086015723.62708.1311080904357.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Edson Tirelli resolved JBRULES-2992.
------------------------------------

    Resolution: Rejected


Thomas, the use of single escapes for regex was deprecated in 5.0 and maintained just for backward compatibility with 4.x during 2 years. With the parser rewrite in 5.2, we thought it was time to remove that and handle escapes the 5.x way (i.e., like in java) with double escapes. 

I am closing this ticket, but if there is a reason to still support single escapes for regex, feel free to reopen this ticket and let us know and we might consider reimplementing the processStringScapes. 



> Could not parse escaped characters
> ----------------------------------
>
>                 Key: JBRULES-2992
>                 URL: https://issues.jboss.org/browse/JBRULES-2992
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.2.0.M2
>            Reporter: Tom?? Schlosser
>            Assignee: Edson Tirelli
>             Fix For: 5.3.0.Beta1
>
>
> When trying to parse rule:
> rule "Regex-A"
> 	when
> 		Person(name matches "\w\w\d{3}\w\w")
> 	then
> 		insert(new Message("Regex-A working"));
> end
> I get following exception:
> Unable to Analyse Expression name ~= "\w\w\d{3}\w\w": [Error: illegal escape sequence: w] [Near : {... name ~= "\w\w\d{3}\w\w" ....}] ^ [Line: 1, Column: 22] : [Rule name='Regex-A']
> use of KnowledgeBuilder property 'drools.parser.processStringEscapes' seems to have no effect. Worked in 5.1

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Tue Jul 19 09:08:24 2011
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Tue, 19 Jul 2011 09:08:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-2992) Could not parse
 escaped characters
In-Reply-To: <1959743421.7947.1303804938478.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <672612469.62710.1311080904403.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Edson Tirelli closed JBRULES-2992.
----------------------------------



> Could not parse escaped characters
> ----------------------------------
>
>                 Key: JBRULES-2992
>                 URL: https://issues.jboss.org/browse/JBRULES-2992
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.2.0.M2
>            Reporter: Tom?? Schlosser
>            Assignee: Edson Tirelli
>             Fix For: 5.3.0.Beta1
>
>
> When trying to parse rule:
> rule "Regex-A"
> 	when
> 		Person(name matches "\w\w\d{3}\w\w")
> 	then
> 		insert(new Message("Regex-A working"));
> end
> I get following exception:
> Unable to Analyse Expression name ~= "\w\w\d{3}\w\w": [Error: illegal escape sequence: w] [Near : {... name ~= "\w\w\d{3}\w\w" ....}] ^ [Line: 1, Column: 22] : [Rule name='Regex-A']
> use of KnowledgeBuilder property 'drools.parser.processStringEscapes' seems to have no effect. Worked in 5.1

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Tue Jul 19 09:28:23 2011
From: jira-events at lists.jboss.org (Max Rydahl Andersen (JIRA))
Date: Tue, 19 Jul 2011 09:28:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1341) Link to console on
 startup page fails when running in EC2/limited network with any-address
Message-ID: <990093973.62820.1311082103907.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Link to console on startup page fails when running in EC2/limited network with any-address
------------------------------------------------------------------------------------------

                 Key: AS7-1341
                 URL: https://issues.jboss.org/browse/AS7-1341
             Project: Application Server 7
          Issue Type: Bug
            Reporter: Max Rydahl Andersen


Not sure if this is supposed to work but seems it could be detected and then handled better.

Started AS7 on an EC2 instance with:

 <interfaces>
        <interface name="management">
            <any-address/>
        </interface>
        <interface name="public">
            <any-address/>
        </interface>
    </interfaces>

to have it actually be available from the outside.

Then going to http://<echostname>:8080 the http://<echohostname>:8080/console link on the frontpage redirects to http://0.0.0.0:9990/console

which doesn't resolve to anything anywhere ;)

I would expect an error page as when the management console is not available at all or at least use the same url as the incoming request.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 09:28:23 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Tue, 19 Jul 2011 09:28:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1342)
 :test-connection-in-pool fails in a strange way
Message-ID: <1352163347.62821.1311082103928.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

:test-connection-in-pool fails in a strange way
-----------------------------------------------

                 Key: AS7-1342
                 URL: https://issues.jboss.org/browse/AS7-1342
             Project: Application Server 7
          Issue Type: Bug
          Components: JCA
    Affects Versions: 7.0.0.Final
            Reporter: Heiko Rupp
            Assignee: Stefano Maestri


[11:54:03] <+pilhuhn> maeste hi
[11:54:06] <+pilhuhn> what does this mean:
[11:54:07] <+pilhuhn> [domain at localhost:9999 data-source=lalaDS] :test-connection-in-pool
[11:54:07] <+pilhuhn> {
[11:54:07] <+pilhuhn>    "outcome" => "failed",
[11:54:07] <+pilhuhn>    "failure-description" => "failed to invoke operation: failed to match pool. Check JndiName: lalaJNDI",
[11:54:57] <+maeste> that jndiName is not matched
[11:55:19] <+pilhuhn> matched by?
[11:55:34] <+maeste> by the runtime connection invoker
[11:55:35] <+pilhuhn> If it is invalid, creation of the datasource should have failed ?
[11:56:01] <+maeste> BTW maybe it'0s a bug when ds name and jndiName are not the same I'll check
[11:56:14] <+pilhuhn> [domain at localhost:9999 data-source=lalaDS] :read-resource
[11:56:14] <+pilhuhn> {
[11:56:14] <+pilhuhn>    "outcome" => "success",
[11:56:14] <+pilhuhn>    "result" => {
[11:56:14] <+pilhuhn>        "background-validation" => undefined,
[11:56:14] <+pilhuhn>        "background-validation-minutes" => undefined,
[11:56:14] <+pilhuhn>        "blocking-timeout-wait-millis" => undefined,
[11:56:14] <+pilhuhn>        "connection-url" => "jdbc:lala",
[11:56:14] <+pilhuhn>        "driver-name" => "postgresql-9.0-801.jdbc4.jar",
[11:56:14] <+pilhuhn>        "idle-timeout-minutes" => undefined,
[11:56:14] <+pilhuhn>        "jndi-name" => "lalaJNDI",
[11:56:38] <+pilhuhn> I did define an invalid connection URL (on purpose)
[11:56:39] <+maeste> yup probably the problem is mine
[11:56:49] <+maeste> I'll have a look this afternoon
[11:57:53] ChanServ sets mode +v Jaikiran
[11:57:54] <+pilhuhn> ok

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 09:47:38 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 19 Jul 2011 09:47:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-649) Indentation of
 multiline text content in standalone.xml keeps increasing on rewrites
In-Reply-To: <2028263512.28653.1302794853658.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1477226168.62898.1311083258977.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd commented on AS7-649:
---------------------------------

This element value should definitely be collapsing whitespace on read before the value goes into the model, and recreating it on write.

> Indentation of multiline text content in standalone.xml keeps increasing on rewrites
> ------------------------------------------------------------------------------------
>
>                 Key: AS7-649
>                 URL: https://issues.jboss.org/browse/AS7-649
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: XML Frameworks
>            Reporter: David Bosschaert
>            Priority: Minor
>
> The standalone.xml file contains some XML tags that contain multi-line XML text, e.g.:
> {code}<property name="org.jboss.osgi.system.modules">
>     org.apache.log4j,
>     org.jboss.as.osgi,
>     javax.inject.api,
>     ...{code}
> The problem is that every automatic rewrite of the standalone.xml (e.g. when you deploy a new thing) the indentation increases from the 2nd line of the text, so after the first rewrite it looks like this:
> {code}<property name="org.jboss.osgi.system.modules">
>     org.apache.log4j,
>             org.jboss.as.osgi,
>             javax.inject.api,
>     ...{code}
> after a few deploys it ends up looking like this:
> {code}<property name="org.jboss.osgi.system.modules">
>     org.apache.log4j,
>                                                                                             org.jboss.as.osgi,
>                                                                                             javax.inject.api,
>     ...{code}
> Pretty ugly :(
> Would be nice if the indentation could be left untouched.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 09:53:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 19 Jul 2011 09:53:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1307) Server does not start
 unless CONSOLE handler is specified in logging.properties.
In-Reply-To: <1586608485.59105.1310955203644.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <71407182.62906.1311083603739.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd updated AS7-1307:
-----------------------------

    Fix Version/s: 7.0.1.Final
                   7.1.0.Alpha1


That's a weird one.  Thanks for the report.

> Server does not start unless CONSOLE handler is specified in logging.properties.
> --------------------------------------------------------------------------------
>
>                 Key: AS7-1307
>                 URL: https://issues.jboss.org/browse/AS7-1307
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.0.0.Final
>         Environment: Ubuntu 10.04 AMD64
> java version "1.6.0_20"
> Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
> Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
>            Reporter: Hanai Shisei
>            Assignee: David Lloyd
>             Fix For: 7.0.1.Final, 7.1.0.Alpha1
>
>
> If I change the logging configuration (standalone/configuration/logging.properties) as the following to prevent console logging:
> #logger.handlers=FILE,CONSOLE
> logger.handlers=FILE
> Server does not start. The log file (standalone/log/boot.log) seems broken and sometimes OutOfMemoryError is recorded:
> 10:42:26,615 INFO  [stdout] ]): java.lang.OutOfMemoryError: Java heap space
> 10:42:26,615 INFO  [stdout] 	at java.util.Arrays.copyOf(Arrays.java:2882) [:1.6.0_20]
> 10:42:26,615 INFO  [stdout] 	at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100) [:1.6.0_20]
> 10:42:26,615 INFO  [stdout] 	at java.lang.StringBuilder.append(StringBuilder.java:130) [:1.6.0_20]
> 10:42:26,615 INFO  [stdout] 	at java.lang.StringBuilder.append(StringBuilder.java:171) [:1.6.0_20]
> 10:42:26,615 INFO  [stdout] 	at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:157) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,615 INFO  [stdout] 	at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:64) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:283) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:291) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.Logger.logRaw(Logger.java:649) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.Logger.log(Logger.java:434) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)
> 10:42:26,616 INFO  [stdout] 	at org.jboss.stdio.WriterOutputStream.finish(WriterOutputStream.java:137)
> 10:42:26,616 INFO  [stdout] 	at org.jboss.stdio.WriterOutputStream.write(WriterOutputStream.java:106)
> 10:42:26,616 INFO  [stdout] 	at java.io.PrintStream.write(PrintStream.java:430) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.stdio.StdioContext$DelegatingPrintStream.write(StdioContext.java:225)
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.handlers.UncloseableOutputStream.write(UncloseableOutputStream.java:47) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:263) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:106) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:116) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at java.io.OutputStreamWriter.write(OutputStreamWriter.java:203) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at java.io.Writer.write(Writer.java:140) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:68) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:64) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:283) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:291) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.Logger.logRaw(Logger.java:649) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.Logger.log(Logger.java:434) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 10:00:24 2011
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Tue, 19 Jul 2011 10:00:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-8297) Weld throws error
 No active contexts for scope type javax.enterprise.context.RequestScoped
Message-ID: <383252822.62913.1311084024792.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Ales Justin commented on JBAS-8297:
-----------------------------------

https://issues.apache.org/bugzilla/show_bug.cgi?id=50789


> Weld throws error No active contexts for scope type javax.enterprise.context.RequestScoped
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-8297
>                 URL: https://issues.jboss.org/browse/JBAS-8297
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>          Components: Weld/CDI
>         Environment: JBoss 6.0.0.M2, Windows XP SP3
>            Reporter: Marcos Antonio
>            Assignee: Ales Justin
>             Fix For: 6.1.0
>
>         Attachments: solicitacoes.zip
>
>
> 2010-04-22 09:55:36,484 WARN  [org.apache.catalina.authenticator.FormAuthenticator] (http-127.0.0.1-8080-1) Unexpected error forwarding to login page: javax.servlet.ServletException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 10:02:23 2011
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Tue, 19 Jul 2011 10:02:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-8297) Weld throws error No
 active contexts for scope type javax.enterprise.context.RequestScoped
Message-ID: <2019168415.62932.1311084143942.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Ales Justin updated JBAS-8297:
------------------------------

    Comment: was deleted

(was: https://issues.apache.org/bugzilla/show_bug.cgi?id=50789
)


> Weld throws error No active contexts for scope type javax.enterprise.context.RequestScoped
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-8297
>                 URL: https://issues.jboss.org/browse/JBAS-8297
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>          Components: Weld/CDI
>         Environment: JBoss 6.0.0.M2, Windows XP SP3
>            Reporter: Marcos Antonio
>            Assignee: Ales Justin
>             Fix For: 6.1.0
>
>         Attachments: solicitacoes.zip
>
>
> 2010-04-22 09:55:36,484 WARN  [org.apache.catalina.authenticator.FormAuthenticator] (http-127.0.0.1-8080-1) Unexpected error forwarding to login page: javax.servlet.ServletException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 10:02:25 2011
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Tue, 19 Jul 2011 10:02:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-8297) Weld throws error
 No active contexts for scope type javax.enterprise.context.RequestScoped
Message-ID: <959431549.62980.1311084145326.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Ales Justin reassigned JBAS-8297:
---------------------------------

    Assignee: Remy Maucherat  (was: Ales Justin)


This appears to be a web request handling order issue -- JBossWeb' task.


> Weld throws error No active contexts for scope type javax.enterprise.context.RequestScoped
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-8297
>                 URL: https://issues.jboss.org/browse/JBAS-8297
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>          Components: Weld/CDI
>         Environment: JBoss 6.0.0.M2, Windows XP SP3
>            Reporter: Marcos Antonio
>            Assignee: Remy Maucherat
>             Fix For: 6.1.0
>
>         Attachments: solicitacoes.zip
>
>
> 2010-04-22 09:55:36,484 WARN  [org.apache.catalina.authenticator.FormAuthenticator] (http-127.0.0.1-8080-1) Unexpected error forwarding to login page: javax.servlet.ServletException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 10:04:23 2011
From: jira-events at lists.jboss.org (Andre Dietisheim (JIRA))
Date: Tue, 19 Jul 2011 10:04:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1341) Link to console on
 startup page fails when running in EC2/limited network with any-address
In-Reply-To: <990093973.62820.1311082103907.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1946439985.62998.1311084263722.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Andre Dietisheim commented on AS7-1341:
---------------------------------------

The management port seems configured correctly:

{xml}
<management-interfaces>
   <native-interface interface="management" port="9999"/>
   <http-interface interface="management" port="9990"/>
</management-interfaces>
{xml}

Nevertheless, if I try to substitute the 0.0.0.0:9990 by the proper ec2 address: ec2-107-20-15-112.compute-1.amazonaws.com:9990/console
I get redirected to http://ec2-107-20-15-112.compute-1.amazonaws.com/:9990/console which is not valid either.

> Link to console on startup page fails when running in EC2/limited network with any-address
> ------------------------------------------------------------------------------------------
>
>                 Key: AS7-1341
>                 URL: https://issues.jboss.org/browse/AS7-1341
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: Max Rydahl Andersen
>
> Not sure if this is supposed to work but seems it could be detected and then handled better.
> Started AS7 on an EC2 instance with:
>  <interfaces>
>         <interface name="management">
>             <any-address/>
>         </interface>
>         <interface name="public">
>             <any-address/>
>         </interface>
>     </interfaces>
> to have it actually be available from the outside.
> Then going to http://<echostname>:8080 the http://<echohostname>:8080/console link on the frontpage redirects to http://0.0.0.0:9990/console
> which doesn't resolve to anything anywhere ;)
> I would expect an error page as when the management console is not available at all or at least use the same url as the incoming request.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 10:04:23 2011
From: jira-events at lists.jboss.org (Andre Dietisheim (JIRA))
Date: Tue, 19 Jul 2011 10:04:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-1341) Link to
 console on startup page fails when running in EC2/limited network with
 any-address
In-Reply-To: <990093973.62820.1311082103907.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2002339830.63001.1311084263810.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Andre Dietisheim edited comment on AS7-1341 at 7/19/11 10:02 AM:
-----------------------------------------------------------------

The management port seems configured correctly:

{code}
<management-interfaces>
   <native-interface interface="management" port="9999"/>
   <http-interface interface="management" port="9990"/>
</management-interfaces>
{code}

Nevertheless, if I try to substitute the 0.0.0.0:9990 by the proper ec2 address: ec2-107-20-15-112.compute-1.amazonaws.com:9990/console
I get redirected to http://ec2-107-20-15-112.compute-1.amazonaws.com/:9990/console which is not valid either.

      was (Author: adietish):
    The management port seems configured correctly:

{xml}
<management-interfaces>
   <native-interface interface="management" port="9999"/>
   <http-interface interface="management" port="9990"/>
</management-interfaces>
{xml}

Nevertheless, if I try to substitute the 0.0.0.0:9990 by the proper ec2 address: ec2-107-20-15-112.compute-1.amazonaws.com:9990/console
I get redirected to http://ec2-107-20-15-112.compute-1.amazonaws.com/:9990/console which is not valid either.
  
> Link to console on startup page fails when running in EC2/limited network with any-address
> ------------------------------------------------------------------------------------------
>
>                 Key: AS7-1341
>                 URL: https://issues.jboss.org/browse/AS7-1341
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: Max Rydahl Andersen
>
> Not sure if this is supposed to work but seems it could be detected and then handled better.
> Started AS7 on an EC2 instance with:
>  <interfaces>
>         <interface name="management">
>             <any-address/>
>         </interface>
>         <interface name="public">
>             <any-address/>
>         </interface>
>     </interfaces>
> to have it actually be available from the outside.
> Then going to http://<echostname>:8080 the http://<echohostname>:8080/console link on the frontpage redirects to http://0.0.0.0:9990/console
> which doesn't resolve to anything anywhere ;)
> I would expect an error page as when the management console is not available at all or at least use the same url as the incoming request.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 10:04:23 2011
From: jira-events at lists.jboss.org (Andre Dietisheim (JIRA))
Date: Tue, 19 Jul 2011 10:04:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-1341) Link to
 console on startup page fails when running in EC2/limited network with
 any-address
In-Reply-To: <990093973.62820.1311082103907.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1179918182.63005.1311084263931.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Andre Dietisheim edited comment on AS7-1341 at 7/19/11 10:03 AM:
-----------------------------------------------------------------

The management port seems configured correctly:

{code}
<management-interfaces>
   <native-interface interface="management" port="9999"/>
   <http-interface interface="management" port="9990"/>
</management-interfaces>
{code}

Nevertheless, if I try to substitute the http://0.0.0.0:9990 by the proper ec2 address: http://ec2-107-20-15-112.compute-1.amazonaws.com:9990/console
I get redirected to http://ec2-107-20-15-112.compute-1.amazonaws.com/:9990/console which is not valid either.

      was (Author: adietish):
    The management port seems configured correctly:

{code}
<management-interfaces>
   <native-interface interface="management" port="9999"/>
   <http-interface interface="management" port="9990"/>
</management-interfaces>
{code}

Nevertheless, if I try to substitute the 0.0.0.0:9990 by the proper ec2 address: ec2-107-20-15-112.compute-1.amazonaws.com:9990/console
I get redirected to http://ec2-107-20-15-112.compute-1.amazonaws.com/:9990/console which is not valid either.
  
> Link to console on startup page fails when running in EC2/limited network with any-address
> ------------------------------------------------------------------------------------------
>
>                 Key: AS7-1341
>                 URL: https://issues.jboss.org/browse/AS7-1341
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: Max Rydahl Andersen
>
> Not sure if this is supposed to work but seems it could be detected and then handled better.
> Started AS7 on an EC2 instance with:
>  <interfaces>
>         <interface name="management">
>             <any-address/>
>         </interface>
>         <interface name="public">
>             <any-address/>
>         </interface>
>     </interfaces>
> to have it actually be available from the outside.
> Then going to http://<echostname>:8080 the http://<echohostname>:8080/console link on the frontpage redirects to http://0.0.0.0:9990/console
> which doesn't resolve to anything anywhere ;)
> I would expect an error page as when the management console is not available at all or at least use the same url as the incoming request.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 10:19:24 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 19 Jul 2011 10:19:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1320) Parsing issue in
 Logging Subsystem - level is required by parser, but not schema
In-Reply-To: <1929200590.60734.1311003623635.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <401441154.63042.1311085164652.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd reassigned AS7-1320:
--------------------------------

    Assignee: James Perkins  (was: David Lloyd)


Another validation issue.

> Parsing issue in Logging Subsystem - level is required by parser, but not schema
> --------------------------------------------------------------------------------
>
>                 Key: AS7-1320
>                 URL: https://issues.jboss.org/browse/AS7-1320
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.0.0.Final
>            Reporter: John Bailey
>            Assignee: James Perkins
>             Fix For: 7.0.1.Final
>
>
> There seems to be an issue with the handler element parsing that expects the level and encoding to be defined, but they are both listed as minOccurs="0" in the schema.  
> Causes stack traces like the following:
> 10:31:32,371 ERROR [stderr] Exception in thread "Controller Boot Thread" java.lang.RuntimeException: org.jboss.as.controller.persistence.ConfigurationPersistenceException: Failed to parse configuration
> 10:31:32,371 ERROR [stderr] 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:89)
> 10:31:32,386 ERROR [stderr] 	at java.lang.Thread.run(Unknown Source)
> 10:31:32,386 ERROR [stderr] Caused by: org.jboss.as.controller.persistence.ConfigurationPersistenceException: Failed to parse configuration
> 10:31:32,386 ERROR [stderr] 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:115)
> 10:31:32,386 ERROR [stderr] 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:104)
> 10:31:32,386 ERROR [stderr] 	at org.jboss.as.server.ServerService.boot(ServerService.java:193)
> 10:31:32,386 ERROR [stderr] 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:83)
> 10:31:32,402 ERROR [stderr] 	... 1 more
> 10:31:32,402 ERROR [stderr] Caused by: java.lang.IllegalArgumentException: newValue is null
> 10:31:32,417 ERROR [stderr] 	at org.jboss.dmr.ModelNode.set(ModelNode.java:349)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.logging.LoggingSubsystemParser.parseSizeRotatingHandlerElement(LoggingSubsystemParser.java:704)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.logging.LoggingSubsystemParser.readElement(LoggingSubsystemParser.java:145)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.logging.LoggingSubsystemParser.readElement(LoggingSubsystemParser.java:84)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:100)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.controller.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:311)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.controller.parsing.StandaloneXml.readServerElement(StandaloneXml.java:163)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.controller.parsing.StandaloneXml.readElement(StandaloneXml.java:91)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.controller.parsing.StandaloneXml.readElement(StandaloneXml.java:79)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:100)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:59)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:107)
> 10:31:32,417 ERROR [stderr] 	... 4 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 10:21:23 2011
From: jira-events at lists.jboss.org (=?UTF-8?Q?Christian_Schl=C3=BCter_=28JIRA=29?=)
Date: Tue, 19 Jul 2011 10:21:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-2262) When throwing
 an application exception in a method that is annotated with NOT_SUPPORTED
 it should not wrap the application Exception.
In-Reply-To: <546050987.62390.1311072023666.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1418033224.63049.1311085283742.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Christian Schl?ter commented on EJBTHREE-2262:
----------------------------------------------

I think this is not a duplicate issue.
EJBTHREE-2261 is about the definition of an application exception.
This case complains about inconsistent behaviour in jboss:
With NOT_SUPPORTED the exception is handled as non-application exception. In any other case it is.
The interpretation of application definition (however it is defined) must be consistent and not dependand on a transaction-handling annotation.

> When throwing an application exception in a method that is annotated with NOT_SUPPORTED it should not wrap the application Exception.
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-2262
>                 URL: https://issues.jboss.org/browse/EJBTHREE-2262
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Shaun Appleton
>         Attachments: stateless_00500318.zip
>
>
> When throwing an application exception in a method that is annotated with NOT_SUPPORTED it should not wrap the application Exception.
> What currently happen is that it is wrapped in an EJBException instead of being thrown un-wrapped.
> See Table 14 p361. of jsr-220 spec
> This has been tested on EAP 5.1.0

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Tue Jul 19 10:33:23 2011
From: jira-events at lists.jboss.org (Hanai Shisei (JIRA))
Date: Tue, 19 Jul 2011 10:33:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1307) Server does not
 start unless CONSOLE handler is specified in logging.properties.
In-Reply-To: <1586608485.59105.1310955203644.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <761315891.63139.1311086003661.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Hanai Shisei commented on AS7-1307:
-----------------------------------

I noticed the issue goes away once I comment out the following line in standalone/configuration/standalone.xml:


                <handlers>
<!--                    <handler name="CONSOLE"/> -->
                    <handler name="FILE"/>
                </handlers>

I'm not sure what is the right configuration anyway...

> Server does not start unless CONSOLE handler is specified in logging.properties.
> --------------------------------------------------------------------------------
>
>                 Key: AS7-1307
>                 URL: https://issues.jboss.org/browse/AS7-1307
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.0.0.Final
>         Environment: Ubuntu 10.04 AMD64
> java version "1.6.0_20"
> Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
> Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
>            Reporter: Hanai Shisei
>            Assignee: David Lloyd
>             Fix For: 7.0.1.Final, 7.1.0.Alpha1
>
>
> If I change the logging configuration (standalone/configuration/logging.properties) as the following to prevent console logging:
> #logger.handlers=FILE,CONSOLE
> logger.handlers=FILE
> Server does not start. The log file (standalone/log/boot.log) seems broken and sometimes OutOfMemoryError is recorded:
> 10:42:26,615 INFO  [stdout] ]): java.lang.OutOfMemoryError: Java heap space
> 10:42:26,615 INFO  [stdout] 	at java.util.Arrays.copyOf(Arrays.java:2882) [:1.6.0_20]
> 10:42:26,615 INFO  [stdout] 	at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100) [:1.6.0_20]
> 10:42:26,615 INFO  [stdout] 	at java.lang.StringBuilder.append(StringBuilder.java:130) [:1.6.0_20]
> 10:42:26,615 INFO  [stdout] 	at java.lang.StringBuilder.append(StringBuilder.java:171) [:1.6.0_20]
> 10:42:26,615 INFO  [stdout] 	at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:157) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,615 INFO  [stdout] 	at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:64) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:283) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:291) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.Logger.logRaw(Logger.java:649) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.Logger.log(Logger.java:434) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)
> 10:42:26,616 INFO  [stdout] 	at org.jboss.stdio.WriterOutputStream.finish(WriterOutputStream.java:137)
> 10:42:26,616 INFO  [stdout] 	at org.jboss.stdio.WriterOutputStream.write(WriterOutputStream.java:106)
> 10:42:26,616 INFO  [stdout] 	at java.io.PrintStream.write(PrintStream.java:430) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.stdio.StdioContext$DelegatingPrintStream.write(StdioContext.java:225)
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.handlers.UncloseableOutputStream.write(UncloseableOutputStream.java:47) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:263) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:106) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:116) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at java.io.OutputStreamWriter.write(OutputStreamWriter.java:203) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at java.io.Writer.write(Writer.java:140) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:68) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:64) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:283) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:291) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.Logger.logRaw(Logger.java:649) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.Logger.log(Logger.java:434) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 10:49:24 2011
From: jira-events at lists.jboss.org (Tom Ross (JIRA))
Date: Tue, 19 Jul 2011 10:49:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1889) Duplicate
 messages are produced during cluster failover when a cluster node is
 shutdown
Message-ID: <1376159458.63243.1311086964843.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Duplicate messages are produced during cluster failover when a cluster node is shutdown
---------------------------------------------------------------------------------------

                 Key: JBMESSAGING-1889
                 URL: https://issues.jboss.org/browse/JBMESSAGING-1889
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core
    Affects Versions: 1.4.8.SP1
         Environment: JBoss EAP 5.1.1
            Reporter: Tom Ross
            Assignee: Yong Hao Gao


The scenarion describes a set-up consisting of JBoss cluster and a stand alone JBoss instance hosting a MDB. 

During the test the master node of the JBoss cluster is shutdown using CTRL/C or shutdown.sh script.

The following is a description of the events that hava happened that lead to duplicate messages.

- Message is delivered to a MDB from node-1 of the cluster to a MDB in a transaction. The transaction prepare has failed because the server peer of node-1 is shutting down.

- Message is rolled back and received again in another transaction. This happens at the client side only. Then the transaction is committed on node-2 as the client has failed over to node-2 of the cluster.

- Meanwhile the fact that node-1 is shutting down causes server side failover to happen and the message is failed over to node-2.

- node-2 redelivers the message to the MDB in a separate transaction and committs.

So the message is received twice.



--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 10:49:25 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 19 Jul 2011 10:49:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1341) Link to console on
 startup page fails when running in EC2/limited network with any-address
In-Reply-To: <990093973.62820.1311082103907.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1154977542.63254.1311086965304.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd commented on AS7-1341:
----------------------------------

Using the literal IP address from an {{<interface>}} tag, or using the localAddress of a bound socket, to construct a public URL is always incorrect, at least when said address resolves to {{0.0.0.0}} or {{::}}.  I thought we had a public interface detection mechanism?

> Link to console on startup page fails when running in EC2/limited network with any-address
> ------------------------------------------------------------------------------------------
>
>                 Key: AS7-1341
>                 URL: https://issues.jboss.org/browse/AS7-1341
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: Max Rydahl Andersen
>
> Not sure if this is supposed to work but seems it could be detected and then handled better.
> Started AS7 on an EC2 instance with:
>  <interfaces>
>         <interface name="management">
>             <any-address/>
>         </interface>
>         <interface name="public">
>             <any-address/>
>         </interface>
>     </interfaces>
> to have it actually be available from the outside.
> Then going to http://<echostname>:8080 the http://<echohostname>:8080/console link on the frontpage redirects to http://0.0.0.0:9990/console
> which doesn't resolve to anything anywhere ;)
> I would expect an error page as when the management console is not available at all or at least use the same url as the incoming request.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 10:51:24 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 19 Jul 2011 10:51:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1307) Server does not
 start unless CONSOLE handler is specified in logging.properties.
In-Reply-To: <1586608485.59105.1310955203644.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <674305429.63260.1311087084129.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd commented on AS7-1307:
----------------------------------

I don't get the OOME - it rather looks like somehow when the CONSOLE handler is disabled the boot.log handler tries to log everything in one giant string!  This is a very, very weird bug.

> Server does not start unless CONSOLE handler is specified in logging.properties.
> --------------------------------------------------------------------------------
>
>                 Key: AS7-1307
>                 URL: https://issues.jboss.org/browse/AS7-1307
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.0.0.Final
>         Environment: Ubuntu 10.04 AMD64
> java version "1.6.0_20"
> Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
> Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
>            Reporter: Hanai Shisei
>            Assignee: David Lloyd
>             Fix For: 7.0.1.Final, 7.1.0.Alpha1
>
>
> If I change the logging configuration (standalone/configuration/logging.properties) as the following to prevent console logging:
> #logger.handlers=FILE,CONSOLE
> logger.handlers=FILE
> Server does not start. The log file (standalone/log/boot.log) seems broken and sometimes OutOfMemoryError is recorded:
> 10:42:26,615 INFO  [stdout] ]): java.lang.OutOfMemoryError: Java heap space
> 10:42:26,615 INFO  [stdout] 	at java.util.Arrays.copyOf(Arrays.java:2882) [:1.6.0_20]
> 10:42:26,615 INFO  [stdout] 	at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100) [:1.6.0_20]
> 10:42:26,615 INFO  [stdout] 	at java.lang.StringBuilder.append(StringBuilder.java:130) [:1.6.0_20]
> 10:42:26,615 INFO  [stdout] 	at java.lang.StringBuilder.append(StringBuilder.java:171) [:1.6.0_20]
> 10:42:26,615 INFO  [stdout] 	at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:157) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,615 INFO  [stdout] 	at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:64) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:283) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:291) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.Logger.logRaw(Logger.java:649) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.Logger.log(Logger.java:434) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)
> 10:42:26,616 INFO  [stdout] 	at org.jboss.stdio.WriterOutputStream.finish(WriterOutputStream.java:137)
> 10:42:26,616 INFO  [stdout] 	at org.jboss.stdio.WriterOutputStream.write(WriterOutputStream.java:106)
> 10:42:26,616 INFO  [stdout] 	at java.io.PrintStream.write(PrintStream.java:430) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.stdio.StdioContext$DelegatingPrintStream.write(StdioContext.java:225)
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.handlers.UncloseableOutputStream.write(UncloseableOutputStream.java:47) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:263) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:106) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:116) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at java.io.OutputStreamWriter.write(OutputStreamWriter.java:203) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at java.io.Writer.write(Writer.java:140) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:68) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:64) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:283) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:291) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.Logger.logRaw(Logger.java:649) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.Logger.log(Logger.java:434) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 11:01:23 2011
From: jira-events at lists.jboss.org (Mario Antollini (JIRA))
Date: Tue, 19 Jul 2011 11:01:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1343) wsconsume.bat not
	working
Message-ID: <347005120.63355.1311087683766.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

wsconsume.bat not working
-------------------------

                 Key: AS7-1343
                 URL: https://issues.jboss.org/browse/AS7-1343
             Project: Application Server 7
          Issue Type: Bug
          Components: Console
    Affects Versions: 7.0.0.Final
         Environment: Windows 7
            Reporter: Mario Antollini
            Assignee: Heiko Braun
             Fix For: Open To Community


The file wsconsume.bat under the bin directory does not work.

The problem is in this line: "-Djava.endorsed.dirs=file:%JBOSS_HOME%/modules/com/sun/xml/bin/main;file:%JBOSS_HOME%/modules/javax/xml/ws/api/main\" ^


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 11:47:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 19 Jul 2011 11:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-2257) Create proper
	API component
In-Reply-To: <187131965.3119.1308309983722.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1119580704.63509.1311090443802.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf updated EJBTHREE-2257:
------------------------------------

               Fix Version/s:     (was: 2.0.0-beta-2)
    Component Fix Version(s): 2.0.0-beta-1


> Create proper API component
> ---------------------------
>
>                 Key: EJBTHREE-2257
>                 URL: https://issues.jboss.org/browse/EJBTHREE-2257
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: ext-api
>            Reporter: Carlo de Wolf
>            Priority: Critical
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 11:49:27 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 19 Jul 2011 11:49:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-2261) Allow
 application exceptions to be defined when using the throws clause.
In-Reply-To: <48907981.56263.1310733323687.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <646795589.63513.1311090567500.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf resolved EJBTHREE-2261.
-------------------------------------

    Resolution: Done


> Allow application exceptions to be defined when using the throws clause. 
> -------------------------------------------------------------------------
>
>                 Key: EJBTHREE-2261
>                 URL: https://issues.jboss.org/browse/EJBTHREE-2261
>             Project: EJB 3.0
>          Issue Type: Feature Request
>            Reporter: Shaun Appleton
>            Assignee: Carlo de Wolf
>             Fix For: 2.0.0-beta-2
>
>
> Allow application exceptions to be defined when using the throws clause. 
> This has been incorporated as part of EJBTHREE-2134 and should be allowed for EJB3 used by EAP 5.x
> Depending on the resolution of http://java.net/jira/browse/EJB_SPEC-20 this may be a bug or rfe

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 11:51:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 19 Jul 2011 11:51:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-2253) Do not expose
 any AOP dependency from jboss-ejb3-cache
In-Reply-To: <620865771.5444.1307350687532.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1858554110.63520.1311090683747.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf updated EJBTHREE-2253:
------------------------------------

    Fix Version/s: 2.0.0-beta-3
                       (was: 2.0.0-beta-2)


> Do not expose any AOP dependency from jboss-ejb3-cache
> ------------------------------------------------------
>
>                 Key: EJBTHREE-2253
>                 URL: https://issues.jboss.org/browse/EJBTHREE-2253
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: cache
>            Reporter: Carlo de Wolf
>            Priority: Critical
>             Fix For: 2.0.0-beta-3
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 11:51:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 19 Jul 2011 11:51:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-2230) Create an EJB 3
 implementation for AS 7
In-Reply-To: <1013548088.42996.1294302797966.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1322195207.63524.1311090683920.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Carlo de Wolf updated EJBTHREE-2230:
------------------------------------

    Fix Version/s: 2.0.0-beta-3
                       (was: 2.0.0-beta-2)


> Create an EJB 3 implementation for AS 7
> ---------------------------------------
>
>                 Key: EJBTHREE-2230
>                 URL: https://issues.jboss.org/browse/EJBTHREE-2230
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>            Priority: Critical
>             Fix For: 2.0.0-beta-3
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 11:55:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Tue, 19 Jul 2011 11:55:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1182) Incorrect security
 domain selected for web application.
In-Reply-To: <320201656.33784.1309788924180.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1265536155.63534.1311090923726.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Juergen Zimmermann commented on AS7-1182:
-----------------------------------------

Only jboss-web.xml is working. I tried an Arquillian test with just EJBs and jboss.xml: it doesn't work.

> Incorrect security domain selected for web application.
> -------------------------------------------------------
>
>                 Key: AS7-1182
>                 URL: https://issues.jboss.org/browse/AS7-1182
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: Darran Lofthouse
>         Attachments: test.ear.zip, testcase-src.zip
>
>
> I want to migrate from JBossAS 6 to 7.0.0.CR1. In standalone.xml I declare the following security domain, but get the stacktrace (see below) looking for UsersRolesLoginModule instead of DatabaseServerLoginModule.
> Security domain in standalone.xml:
>    <security-domain name="swe2" cache-type="default">
>       <authentication>
>          <login-module code="Database" flag="required">
>             <module-option name="dsJndiName" value="java:/swe2DS"/>
>             <module-option name="unauthenticatedIdentity" value="gast"/>
>             <module-option name="principalsQuery" value="SELECT password FROM kunde WHERE username=?"/>
>             <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM swe2_role r INNER JOIN kunde k ON r.kunde_fk = k.k_id WHERE k.username=?"/>
>             <module-option name="hashAlgorithm" value="SHA-1"/>
>             <module-option name="hashEncoding" value="base64"/>
>          </login-module>
>       </authentication>
>    </security-domain>
> Stacktrace regarding UsersRolesLoginModule (instead of DatabaseServerLoginModule):
> 16:03:58,528 ERROR [org.jboss.security.auth.spi.UsersRolesLoginModule] (http--127.0.0.1-8080-2) Failed to load users/passwords/role files: java.io.IOException: No properties file: users.properties or defaults: defaultUsers.properties found
> 	at org.jboss.security.auth.spi.Util.loadProperties(Util.java:227) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:188) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:202) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:129) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	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 javax.security.auth.login.LoginContext.invoke(LoginContext.java:756) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683) [:1.6.0_26]
> 	at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:579) [:1.6.0_26]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:411) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:154) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:127) [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:180) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:446) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 12:06:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 19 Jul 2011 12:06:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1182) Incorrect security
 domain selected for web application.
In-Reply-To: <320201656.33784.1309788924180.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1593125506.63556.1311091583874.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse commented on AS7-1182:
---------------------------------------

Ok will check jboss.xml as well

> Incorrect security domain selected for web application.
> -------------------------------------------------------
>
>                 Key: AS7-1182
>                 URL: https://issues.jboss.org/browse/AS7-1182
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: Darran Lofthouse
>         Attachments: test.ear.zip, testcase-src.zip
>
>
> I want to migrate from JBossAS 6 to 7.0.0.CR1. In standalone.xml I declare the following security domain, but get the stacktrace (see below) looking for UsersRolesLoginModule instead of DatabaseServerLoginModule.
> Security domain in standalone.xml:
>    <security-domain name="swe2" cache-type="default">
>       <authentication>
>          <login-module code="Database" flag="required">
>             <module-option name="dsJndiName" value="java:/swe2DS"/>
>             <module-option name="unauthenticatedIdentity" value="gast"/>
>             <module-option name="principalsQuery" value="SELECT password FROM kunde WHERE username=?"/>
>             <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM swe2_role r INNER JOIN kunde k ON r.kunde_fk = k.k_id WHERE k.username=?"/>
>             <module-option name="hashAlgorithm" value="SHA-1"/>
>             <module-option name="hashEncoding" value="base64"/>
>          </login-module>
>       </authentication>
>    </security-domain>
> Stacktrace regarding UsersRolesLoginModule (instead of DatabaseServerLoginModule):
> 16:03:58,528 ERROR [org.jboss.security.auth.spi.UsersRolesLoginModule] (http--127.0.0.1-8080-2) Failed to load users/passwords/role files: java.io.IOException: No properties file: users.properties or defaults: defaultUsers.properties found
> 	at org.jboss.security.auth.spi.Util.loadProperties(Util.java:227) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:188) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:202) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:129) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	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 javax.security.auth.login.LoginContext.invoke(LoginContext.java:756) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683) [:1.6.0_26]
> 	at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:579) [:1.6.0_26]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:411) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:154) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:127) [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:180) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:446) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 13:05:23 2011
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Tue, 19 Jul 2011 13:05:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-8297) Weld throws error
 No active contexts for scope type javax.enterprise.context.RequestScoped
Message-ID: <108160800.64614.1311095123785.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Remy Maucherat commented on JBAS-8297:
--------------------------------------

Ok, assuming this works ok in AS 7, I have no intention to fix this for AS 6.

> Weld throws error No active contexts for scope type javax.enterprise.context.RequestScoped
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-8297
>                 URL: https://issues.jboss.org/browse/JBAS-8297
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>          Components: Weld/CDI
>         Environment: JBoss 6.0.0.M2, Windows XP SP3
>            Reporter: Marcos Antonio
>            Assignee: Remy Maucherat
>             Fix For: 6.1.0
>
>         Attachments: solicitacoes.zip
>
>
> 2010-04-22 09:55:36,484 WARN  [org.apache.catalina.authenticator.FormAuthenticator] (http-127.0.0.1-8080-1) Unexpected error forwarding to login page: javax.servlet.ServletException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 14:05:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 19 Jul 2011 14:05:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1307) Server does not
 start unless CONSOLE handler is specified in logging.properties.
In-Reply-To: <1586608485.59105.1310955203644.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1742925903.64791.1311098723647.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd commented on AS7-1307:
----------------------------------

Might be an issue with the timing around the installation of the stdio redirection handlers.

> Server does not start unless CONSOLE handler is specified in logging.properties.
> --------------------------------------------------------------------------------
>
>                 Key: AS7-1307
>                 URL: https://issues.jboss.org/browse/AS7-1307
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.0.0.Final
>         Environment: Ubuntu 10.04 AMD64
> java version "1.6.0_20"
> Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
> Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
>            Reporter: Hanai Shisei
>            Assignee: David Lloyd
>             Fix For: 7.0.1.Final, 7.1.0.Alpha1
>
>
> If I change the logging configuration (standalone/configuration/logging.properties) as the following to prevent console logging:
> #logger.handlers=FILE,CONSOLE
> logger.handlers=FILE
> Server does not start. The log file (standalone/log/boot.log) seems broken and sometimes OutOfMemoryError is recorded:
> 10:42:26,615 INFO  [stdout] ]): java.lang.OutOfMemoryError: Java heap space
> 10:42:26,615 INFO  [stdout] 	at java.util.Arrays.copyOf(Arrays.java:2882) [:1.6.0_20]
> 10:42:26,615 INFO  [stdout] 	at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100) [:1.6.0_20]
> 10:42:26,615 INFO  [stdout] 	at java.lang.StringBuilder.append(StringBuilder.java:130) [:1.6.0_20]
> 10:42:26,615 INFO  [stdout] 	at java.lang.StringBuilder.append(StringBuilder.java:171) [:1.6.0_20]
> 10:42:26,615 INFO  [stdout] 	at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:157) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,615 INFO  [stdout] 	at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:64) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:283) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:291) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.Logger.logRaw(Logger.java:649) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.Logger.log(Logger.java:434) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)
> 10:42:26,616 INFO  [stdout] 	at org.jboss.stdio.WriterOutputStream.finish(WriterOutputStream.java:137)
> 10:42:26,616 INFO  [stdout] 	at org.jboss.stdio.WriterOutputStream.write(WriterOutputStream.java:106)
> 10:42:26,616 INFO  [stdout] 	at java.io.PrintStream.write(PrintStream.java:430) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.stdio.StdioContext$DelegatingPrintStream.write(StdioContext.java:225)
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.handlers.UncloseableOutputStream.write(UncloseableOutputStream.java:47) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:263) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:106) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:116) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at java.io.OutputStreamWriter.write(OutputStreamWriter.java:203) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at java.io.Writer.write(Writer.java:140) [:1.6.0_20]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:68) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:64) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:283) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:291) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.Logger.logRaw(Logger.java:649) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.logmanager.Logger.log(Logger.java:434) [jboss-logmanager-1.2.0.GA.jar:1.2.0.GA]
> 10:42:26,616 INFO  [stdout] 	at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 17:04:23 2011
From: jira-events at lists.jboss.org (Justin Bertram (JIRA))
Date: Tue, 19 Jul 2011 17:04:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1890) Recovery
 configuration in a cluster is too burdensome
Message-ID: <1818771781.66923.1311109463768.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Recovery configuration in a cluster is too burdensome
-----------------------------------------------------

                 Key: JBMESSAGING-1890
                 URL: https://issues.jboss.org/browse/JBMESSAGING-1890
             Project: JBoss Messaging
          Issue Type: Task
          Components: JMS Clustering
    Affects Versions: 1.4.8.SP1
            Reporter: Justin Bertram


The recovery configuration describe on http://community.jboss.org/wiki/Non-serializableXAResourceErrorFromJBossMessagingJBM-ClusteredSetup is too burdensome, especially for large clusters.  When a new node is added to the cluster then *every* node in the cluster needs a configuration change.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 17:04:23 2011
From: jira-events at lists.jboss.org (Justin Bertram (JIRA))
Date: Tue, 19 Jul 2011 17:04:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1890) Recovery
 configuration in a cluster is too burdensome
In-Reply-To: <1818771781.66923.1311109463768.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1305862736.66927.1311109463915.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Justin Bertram reassigned JBMESSAGING-1890:
-------------------------------------------

    Assignee: Yong Hao Gao


> Recovery configuration in a cluster is too burdensome
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-1890
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1890
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: JMS Clustering
>    Affects Versions: 1.4.8.SP1
>            Reporter: Justin Bertram
>            Assignee: Yong Hao Gao
>
> The recovery configuration describe on http://community.jboss.org/wiki/Non-serializableXAResourceErrorFromJBossMessagingJBM-ClusteredSetup is too burdensome, especially for large clusters.  When a new node is added to the cluster then *every* node in the cluster needs a configuration change.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 18:15:23 2011
From: jira-events at lists.jboss.org (Justin Bertram (JIRA))
Date: Tue, 19 Jul 2011 18:15:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1890) Recovery
 configuration in a cluster is too burdensome
In-Reply-To: <1818771781.66923.1311109463768.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1602614437.66997.1311113723778.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Justin Bertram commented on JBMESSAGING-1890:
---------------------------------------------

I opened JBMESSAGING-1731 awhile back to make it possible for users who wanted to write their own cluster-aware recovery module.  However, this functionality already exists in EAP 5 via the JGroups channel factory.  The 2 JGroups channels used by JBoss Messaging are exposed via JMX (e.g. jboss.jgroups:cluster=DefaultPartition-JMS-CTRL,type=channel and jboss.jgroups:cluster=DefaultPartition-JMS-DATA,type=channel).  Therefore a possible solution to this problem in EAP 5+ is to write a new cluster-aware recovery module using this information.

Another possible solution would be to simply *not* fail-over in-doubt XA transactions to other nodes in the cluster.

> Recovery configuration in a cluster is too burdensome
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-1890
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1890
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: JMS Clustering
>    Affects Versions: 1.4.8.SP1
>            Reporter: Justin Bertram
>            Assignee: Yong Hao Gao
>
> The recovery configuration describe on http://community.jboss.org/wiki/Non-serializableXAResourceErrorFromJBossMessagingJBM-ClusteredSetup is too burdensome, especially for large clusters.  When a new node is added to the cluster then *every* node in the cluster needs a configuration change.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 19:21:23 2011
From: jira-events at lists.jboss.org (Abhijit Sarkar (JIRA))
Date: Tue, 19 Jul 2011 19:21:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1324) RESTful service
 Servlet configuration fails with ClassCastException
In-Reply-To: <938495355.61579.1311040223621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1268377275.67205.1311117683689.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Abhijit Sarkar commented on AS7-1324:
-------------------------------------

$ ./standalone.sh --server-config=standalone-preview.xml

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

19:13:25,625 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/movieservicerestful]] (MSC service thread 1-2) Exception sending context initialized event to listener instance of class org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap: java.lang.NoClassDefFoundError: javax/servlet/ServletContext

...

Caused by: java.lang.ClassNotFoundException: javax.servlet.ServletContext from [Module "org.scannotation.scannotation:main" from local module loader @7cf1bb78 (roots: /home/abhijit/Workspace/jboss/modules)]
	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)

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

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-war-plugin</artifactId>
  <version>2.1.1</version>
  <configuration>
    <archive>
      <manifestEntries>
        <Dependencies>org.jboss.resteasy.resteasy-jaxrs,javax.servlet.api</Dependencies>
      </manifestEntries>
    </archive>
  </configuration>
</plugin>

> RESTful service Servlet configuration fails with ClassCastException
> -------------------------------------------------------------------
>
>                 Key: AS7-1324
>                 URL: https://issues.jboss.org/browse/AS7-1324
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>         Environment: Ubuntu 11.04 64 bit, Sun Java 1.6.0_26, JBoss AS 7.0.0.Final 
>            Reporter: Abhijit Sarkar
>            Assignee: Alessio Soldano
>
> RESTful service fails to deploy with following exception when configured as a Servlet in web.xml. If not configured in web.xml, the service is unavailable on the deployed context path.
> 00:29:32,684 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/movieservicerestful].[MovieServiceRestful]] (http--127.0.0.1-9090-2) Allocate exception for servlet MovieServiceRestful: java.lang.ClassCastException: MovieServiceRestful cannot be cast to javax.servlet.Servlet
> <servlet>
>   <servlet-name>MovieServiceRestful</servlet-name>
>   <servlet-class>MovieServiceRestful</servlet-class>
> </servlet>
> <servlet-mapping>
>   <servlet-name>MovieServiceRestful</servlet-name>
>   <url-pattern>/*</url-pattern>
> </servlet-mapping>

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 19:23:23 2011
From: jira-events at lists.jboss.org (Abhijit Sarkar (JIRA))
Date: Tue, 19 Jul 2011 19:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1323) @Resource injection
 on WebServiceContext fails
In-Reply-To: <48156148.61562.1311039863763.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1409531889.67210.1311117803683.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Abhijit Sarkar commented on AS7-1323:
-------------------------------------

$ ./standalone.sh --server-config=standalone-preview.xml

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

19:13:25,625 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/movieservicerestful]] (MSC service thread 1-2) Exception sending context initialized event to listener instance of class org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap: java.lang.NoClassDefFoundError: javax/servlet/ServletContext

...

Caused by: java.lang.ClassNotFoundException: javax.servlet.ServletContext from [Module "org.scannotation.scannotation:main" from local module loader @7cf1bb78 (roots: /home/abhijit/Workspace/jboss/modules)]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)

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

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<archive>
<manifestEntries>
<Dependencies>org.jboss.resteasy.resteasy-jaxrs,javax.servlet.api</Dependencies>
</manifestEntries>
</archive>
</configuration>
</plugin>

> @Resource injection on WebServiceContext fails
> ----------------------------------------------
>
>                 Key: AS7-1323
>                 URL: https://issues.jboss.org/browse/AS7-1323
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>         Environment: Ubuntu 11.04 64 bit, Sun Java 1.6.0_26, JBoss AS 7.0.0.Final
>            Reporter: Abhijit Sarkar
>            Assignee: Alessio Soldano
>
> 00:20:55,004 WARN  [org.jboss.as.ee.component.ResourceInjectionAnnotationParsingProcessor] (MSC service thread 1-4) Can't handle @Resource for ENC name: MovieServiceRestful/wsCtx on class MovieServiceRestful since it's missing a "lookup" (or "mappedName") value and isn't of any known type.
> @WebServiceProvider
> @BindingType(value = HTTPBinding.HTTP_BINDING)
> public class MovieServiceRestful implements Provider<Source> {
>     @Resource
>     protected WebServiceContext wsCtx;
>     ...
> }

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 20:48:23 2011
From: jira-events at lists.jboss.org (Dan Allen (JIRA))
Date: Tue, 19 Jul 2011 20:48:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1152) Support Deployment
 introspection using ProtocolMetadata in the Arquillian Containers
In-Reply-To: <2024534842.29230.1309422683684.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1498527641.67263.1311122903627.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Dan Allen commented on AS7-1152:
--------------------------------

I'd like to add that this patch is crucial for the demonstration of Arquillian. We use the @ArquillianResource test enrichment throughout the Arquillian Showcase.

> Support Deployment introspection using ProtocolMetadata in the Arquillian Containers
> ------------------------------------------------------------------------------------
>
>                 Key: AS7-1152
>                 URL: https://issues.jboss.org/browse/AS7-1152
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Test Suite
>    Affects Versions: 7.0.0.CR1
>            Reporter: Aslak Knutsen
>            Assignee: Aslak Knutsen
>             Fix For: 7.0.1.Final
>
>
> on deploy, the Arquillian Containers should return a ProtocolMetadata object that describes the content of the Deployment.
> e.g. Which HTTP contexts (ip/port) are there, which Servlets etc. 
> This can be used for injection of URL's to the Deployed context, e.g. @ArquillianResource(MyServlet.class) URL url;
> The same is used by the ServletProtocol to discover the correct web context to call to invoke the test (this does not currently work at all with AS7)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 21:09:23 2011
From: jira-events at lists.jboss.org (Abhijit Sarkar (JIRA))
Date: Tue, 19 Jul 2011 21:09:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-1324) RESTful
 service Servlet configuration fails with ClassCastException
In-Reply-To: <938495355.61579.1311040223621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <512214623.67347.1311124163840.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Abhijit Sarkar edited comment on AS7-1324 at 7/19/11 9:08 PM:
--------------------------------------------------------------

$ ./standalone.sh --server-config=standalone-preview.xml

{code}

21:01:09,038 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/movieservicerestful]] (MSC service thread 1-3) Exception sending context initialized event to listener instance of class org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap: java.lang.NoClassDefFoundError: javax/servlet/ServletContext
	at org.scannotation.WarUrlFinder.findWebInfClassesPath(WarUrlFinder.java:56) [scannotation-1.0.2.jar:]
	at org.jboss.resteasy.plugins.server.servlet.ListenerBootstrap.getScanningUrls(ListenerBootstrap.java:64) [resteasy-jaxrs-2.2.1.GA.jar:]	

21:01:09,044 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-3) Error listenerStart
21:01:09,045 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-3) Context [/movieservicerestful] startup failed due to previous errors
21:01:09,045 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/movieservicerestful]] (MSC service thread 1-3) Exception sending context destroyed event to listener instance of class org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap: java.lang.NullPointerException
	at org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap.contextDestroyed(ResteasyBootstrap.java:37) [resteasy-jaxrs-2.2.1.GA.jar:]

{code}

{code:xml}
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-war-plugin</artifactId>
  <version>2.1.1</version>
  <configuration>
    <archive>
      <manifestEntries>
        <Dependencies>org.jboss.resteasy.resteasy-jaxrs export service,javax.servlet.api export service,org.scannotation.scannotation export service</Dependencies>
      </manifestEntries>
    </archive>
  </configuration>
</plugin>
{code}

      was (Author: Abhi0123):
    $ ./standalone.sh --server-config=standalone-preview.xml

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

19:13:25,625 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/movieservicerestful]] (MSC service thread 1-2) Exception sending context initialized event to listener instance of class org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap: java.lang.NoClassDefFoundError: javax/servlet/ServletContext

...

Caused by: java.lang.ClassNotFoundException: javax.servlet.ServletContext from [Module "org.scannotation.scannotation:main" from local module loader @7cf1bb78 (roots: /home/abhijit/Workspace/jboss/modules)]
	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)

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

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-war-plugin</artifactId>
  <version>2.1.1</version>
  <configuration>
    <archive>
      <manifestEntries>
        <Dependencies>org.jboss.resteasy.resteasy-jaxrs,javax.servlet.api</Dependencies>
      </manifestEntries>
    </archive>
  </configuration>
</plugin>
  
> RESTful service Servlet configuration fails with ClassCastException
> -------------------------------------------------------------------
>
>                 Key: AS7-1324
>                 URL: https://issues.jboss.org/browse/AS7-1324
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>         Environment: Ubuntu 11.04 64 bit, Sun Java 1.6.0_26, JBoss AS 7.0.0.Final 
>            Reporter: Abhijit Sarkar
>            Assignee: Alessio Soldano
>
> RESTful service fails to deploy with following exception when configured as a Servlet in web.xml. If not configured in web.xml, the service is unavailable on the deployed context path.
> 00:29:32,684 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/movieservicerestful].[MovieServiceRestful]] (http--127.0.0.1-9090-2) Allocate exception for servlet MovieServiceRestful: java.lang.ClassCastException: MovieServiceRestful cannot be cast to javax.servlet.Servlet
> <servlet>
>   <servlet-name>MovieServiceRestful</servlet-name>
>   <servlet-class>MovieServiceRestful</servlet-class>
> </servlet>
> <servlet-mapping>
>   <servlet-name>MovieServiceRestful</servlet-name>
>   <url-pattern>/*</url-pattern>
> </servlet-mapping>

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 21:11:23 2011
From: jira-events at lists.jboss.org (Abhijit Sarkar (JIRA))
Date: Tue, 19 Jul 2011 21:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-1323)
 @Resource injection on WebServiceContext fails
In-Reply-To: <48156148.61562.1311039863763.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <249416539.67353.1311124283731.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Abhijit Sarkar edited comment on AS7-1323 at 7/19/11 9:09 PM:
--------------------------------------------------------------

$ ./standalone.sh --server-config=standalone-preview.xml

{code}

21:01:09,038 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/movieservicerestful]] (MSC service thread 1-3) Exception sending context initialized event to listener instance of class org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap: java.lang.NoClassDefFoundError: javax/servlet/ServletContext
	at org.scannotation.WarUrlFinder.findWebInfClassesPath(WarUrlFinder.java:56) [scannotation-1.0.2.jar:]
	at org.jboss.resteasy.plugins.server.servlet.ListenerBootstrap.getScanningUrls(ListenerBootstrap.java:64) [resteasy-jaxrs-2.2.1.GA.jar:]	

21:01:09,044 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-3) Error listenerStart
21:01:09,045 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-3) Context [/movieservicerestful] startup failed due to previous errors
21:01:09,045 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/movieservicerestful]] (MSC service thread 1-3) Exception sending context destroyed event to listener instance of class org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap: java.lang.NullPointerException
	at org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap.contextDestroyed(ResteasyBootstrap.java:37) [resteasy-jaxrs-2.2.1.GA.jar:]

{code}

{code:xml}
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-war-plugin</artifactId>
  <version>2.1.1</version>
  <configuration>
    <archive>
      <manifestEntries>
        <Dependencies>org.jboss.resteasy.resteasy-jaxrs export service,javax.servlet.api export service,org.scannotation.scannotation export service</Dependencies>
      </manifestEntries>
    </archive>
  </configuration>
</plugin>
{code}

      was (Author: Abhi0123):
    $ ./standalone.sh --server-config=standalone-preview.xml

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

19:13:25,625 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/movieservicerestful]] (MSC service thread 1-2) Exception sending context initialized event to listener instance of class org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap: java.lang.NoClassDefFoundError: javax/servlet/ServletContext

...

Caused by: java.lang.ClassNotFoundException: javax.servlet.ServletContext from [Module "org.scannotation.scannotation:main" from local module loader @7cf1bb78 (roots: /home/abhijit/Workspace/jboss/modules)]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)

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

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<archive>
<manifestEntries>
<Dependencies>org.jboss.resteasy.resteasy-jaxrs,javax.servlet.api</Dependencies>
</manifestEntries>
</archive>
</configuration>
</plugin>
  
> @Resource injection on WebServiceContext fails
> ----------------------------------------------
>
>                 Key: AS7-1323
>                 URL: https://issues.jboss.org/browse/AS7-1323
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>         Environment: Ubuntu 11.04 64 bit, Sun Java 1.6.0_26, JBoss AS 7.0.0.Final
>            Reporter: Abhijit Sarkar
>            Assignee: Alessio Soldano
>
> 00:20:55,004 WARN  [org.jboss.as.ee.component.ResourceInjectionAnnotationParsingProcessor] (MSC service thread 1-4) Can't handle @Resource for ENC name: MovieServiceRestful/wsCtx on class MovieServiceRestful since it's missing a "lookup" (or "mappedName") value and isn't of any known type.
> @WebServiceProvider
> @BindingType(value = HTTPBinding.HTTP_BINDING)
> public class MovieServiceRestful implements Provider<Source> {
>     @Resource
>     protected WebServiceContext wsCtx;
>     ...
> }

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 21:22:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 19 Jul 2011 21:22:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1314)
 LifecycleAnnotationParsingProcessor creates EEClassDescriptions for every
 class, not just component classes
In-Reply-To: <1361011650.59918.1310988096006.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <840018982.67392.1311124943668.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved AS7-1314.
---------------------------------

    Resolution: Done


If an EEClassDescription that is not used by a component fails to load then this will not stop the deployment any more. 

> LifecycleAnnotationParsingProcessor creates EEClassDescriptions for every class, not just component classes 
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1314
>                 URL: https://issues.jboss.org/browse/AS7-1314
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 7.0.0.Final
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 7.0.1.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 21:36:23 2011
From: jira-events at lists.jboss.org (Takayoshi Kimura (JIRA))
Date: Tue, 19 Jul 2011 21:36:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1289) Unnecessary URL
 reconstruction in management console
In-Reply-To: <946052265.54997.1310690303707.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <24245585.67427.1311125783753.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Takayoshi Kimura commented on AS7-1289:
---------------------------------------

With this fix we redirect to provided Host header address. If no Host header, use management interface address.

$ curl -H"Host: ext.example.com:19990" -v http://127.0.0.1:9990/console/
* About to connect() to 127.0.0.1 port 9990 (#0)
*   Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 9990 (#0)
> GET /console/ HTTP/1.1
> User-Agent: curl/7.21.3 (x86_64-redhat-linux-gnu) libcurl/7.21.3 NSS/3.12.10.0 zlib/1.2.5 libidn/1.19 libssh2/1.2.7
> Accept: */*
> Host: ext.example.com:19990
> 
< HTTP/1.1 302 Temporary Redirect
< Transfer-encoding: chunked
< Content-type: text/html
< Location: http://ext.example.com:19990/console/index.html
< Date: Wed, 20 Jul 2011 01:24:23 GMT
< 
* Connection #0 to host 127.0.0.1 left intact
* Closing connection #0

$ curl -v http://localhost:9990/console/
* About to connect() to localhost port 9990 (#0)
*   Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 9990 (#0)
> GET /console/ HTTP/1.1
> User-Agent: curl/7.21.3 (x86_64-redhat-linux-gnu) libcurl/7.21.3 NSS/3.12.10.0 zlib/1.2.5 libidn/1.19 libssh2/1.2.7
> Host: localhost:9990
> Accept: */*
> 
< HTTP/1.1 302 Temporary Redirect
< Transfer-encoding: chunked
< Content-type: text/html
< Location: http://localhost:9990/console/index.html
< Date: Wed, 20 Jul 2011 01:24:39 GMT
< 
* Connection #0 to host localhost left intact
* Closing connection #0


> Unnecessary URL reconstruction in management console 
> -----------------------------------------------------
>
>                 Key: AS7-1289
>                 URL: https://issues.jboss.org/browse/AS7-1289
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Console
>    Affects Versions: 7.0.0.Final
>            Reporter: Takayoshi Kimura
>            Assignee: Takayoshi Kimura
>            Priority: Minor
>
> Management console redirects "/console" to "/console/index.html"and it reconstructs URL from management interface definition. 
> ext.example.com:9990/console -> local.example.com:9990/console/index.html
> This URL reconstruction is not necessary and it's better to keep current URL server/port values.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 21:38:24 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 19 Jul 2011 21:38:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (AS7-1344) JGroups subsystem
 TimerScedulerAdapter throws UOE when using timer-executor
Message-ID: <1983779918.67444.1311125904010.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro moved JBPAPP-6863 to AS7-1344:
-------------------------------------------

              Project: Application Server 7  (was: JBoss Enterprise Application Platform)
                  Key: AS7-1344  (was: JBPAPP-6863)
             Workflow: GIT Pull Request workflow   (was: jira)
    Affects Version/s: 7.0.0.Final
                           (was: EDG 6.0.0 ALPHA)
          Component/s: Clustering
                           (was: Enterprise Data Grid)
             Security:     (was: Public)
       Docs QE Status:   (was: NEW)


> JGroups subsystem TimerScedulerAdapter throws UOE when using timer-executor
> ---------------------------------------------------------------------------
>
>                 Key: AS7-1344
>                 URL: https://issues.jboss.org/browse/AS7-1344
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.Final
>            Reporter: Michal Linhard
>            Assignee: Trustin Lee
>
> http://hudson.qa.jboss.com/hudson/view/EDG6/job/edg-60-stress-client-hotrod-size4/37/console-perf17/consoleText
> {code}
> 07:42:39,535 WARNING [org.jgroups.protocols.UDP] (DiagnosticsHandler,default,perf17-37478) Could not retrieve value of attribute (method) getNumTimerTasks: java.lang.reflect.InvocationTargetException
> [JBoss] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_24]
> [JBoss] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_24]
> [JBoss] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_24]
> [JBoss] 	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_24]
> [JBoss] 	at org.jgroups.stack.Protocol.dumpStats(Protocol.java:272) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at org.jgroups.stack.ProtocolStack.dumpStats(ProtocolStack.java:310) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at org.jgroups.JChannel.dumpStats(JChannel.java:687) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at org.jgroups.JChannel$MyProbeHandler.handleProbe(JChannel.java:2099) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at org.jgroups.protocols.TP$DiagnosticsHandler.handleDiagnosticProbe(TP.java:2165) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at org.jgroups.protocols.TP$DiagnosticsHandler.run(TP.java:2137) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
> [JBoss] Caused by: java.lang.UnsupportedOperationException
> [JBoss] 	at org.jboss.as.clustering.jgroups.TimerSchedulerAdapter.getExecutor(TimerSchedulerAdapter.java:168) [jboss-as-clustering-jgroups-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> [JBoss] 	at org.jboss.as.clustering.jgroups.TimerSchedulerAdapter.size(TimerSchedulerAdapter.java:153) [jboss-as-clustering-jgroups-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> [JBoss] 	at org.jgroups.protocols.TP.getNumTimerTasks(TP.java:714) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	... 11 more
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 21:38:24 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 19 Jul 2011 21:38:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1344) JGroups subsystem
 TimerScedulerAdapter throws UOE when using timer-executor
Message-ID: <162840019.67447.1311125904104.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro updated AS7-1344:
------------------------------

    Description: 
07:42:39,535 WARNING [org.jgroups.protocols.UDP] (DiagnosticsHandler,default,perf17-37478) Could not retrieve value of attribute (method) getNumTimerTasks: java.lang.reflect.InvocationTargetException
[JBoss] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_24]
[JBoss] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_24]
[JBoss] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_24]
[JBoss] 	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_24]
[JBoss] 	at org.jgroups.stack.Protocol.dumpStats(Protocol.java:272) [jgroups-2.12.1.Final.jar:]
[JBoss] 	at org.jgroups.stack.ProtocolStack.dumpStats(ProtocolStack.java:310) [jgroups-2.12.1.Final.jar:]
[JBoss] 	at org.jgroups.JChannel.dumpStats(JChannel.java:687) [jgroups-2.12.1.Final.jar:]
[JBoss] 	at org.jgroups.JChannel$MyProbeHandler.handleProbe(JChannel.java:2099) [jgroups-2.12.1.Final.jar:]
[JBoss] 	at org.jgroups.protocols.TP$DiagnosticsHandler.handleDiagnosticProbe(TP.java:2165) [jgroups-2.12.1.Final.jar:]
[JBoss] 	at org.jgroups.protocols.TP$DiagnosticsHandler.run(TP.java:2137) [jgroups-2.12.1.Final.jar:]
[JBoss] 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
[JBoss] Caused by: java.lang.UnsupportedOperationException
[JBoss] 	at org.jboss.as.clustering.jgroups.TimerSchedulerAdapter.getExecutor(TimerSchedulerAdapter.java:168) [jboss-as-clustering-jgroups-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
[JBoss] 	at org.jboss.as.clustering.jgroups.TimerSchedulerAdapter.size(TimerSchedulerAdapter.java:153) [jboss-as-clustering-jgroups-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
[JBoss] 	at org.jgroups.protocols.TP.getNumTimerTasks(TP.java:714) [jgroups-2.12.1.Final.jar:]
[JBoss] 	... 11 more
{code}

  was:
http://hudson.qa.jboss.com/hudson/view/EDG6/job/edg-60-stress-client-hotrod-size4/37/console-perf17/consoleText

{code}
07:42:39,535 WARNING [org.jgroups.protocols.UDP] (DiagnosticsHandler,default,perf17-37478) Could not retrieve value of attribute (method) getNumTimerTasks: java.lang.reflect.InvocationTargetException
[JBoss] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_24]
[JBoss] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_24]
[JBoss] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_24]
[JBoss] 	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_24]
[JBoss] 	at org.jgroups.stack.Protocol.dumpStats(Protocol.java:272) [jgroups-2.12.1.Final.jar:]
[JBoss] 	at org.jgroups.stack.ProtocolStack.dumpStats(ProtocolStack.java:310) [jgroups-2.12.1.Final.jar:]
[JBoss] 	at org.jgroups.JChannel.dumpStats(JChannel.java:687) [jgroups-2.12.1.Final.jar:]
[JBoss] 	at org.jgroups.JChannel$MyProbeHandler.handleProbe(JChannel.java:2099) [jgroups-2.12.1.Final.jar:]
[JBoss] 	at org.jgroups.protocols.TP$DiagnosticsHandler.handleDiagnosticProbe(TP.java:2165) [jgroups-2.12.1.Final.jar:]
[JBoss] 	at org.jgroups.protocols.TP$DiagnosticsHandler.run(TP.java:2137) [jgroups-2.12.1.Final.jar:]
[JBoss] 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
[JBoss] Caused by: java.lang.UnsupportedOperationException
[JBoss] 	at org.jboss.as.clustering.jgroups.TimerSchedulerAdapter.getExecutor(TimerSchedulerAdapter.java:168) [jboss-as-clustering-jgroups-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
[JBoss] 	at org.jboss.as.clustering.jgroups.TimerSchedulerAdapter.size(TimerSchedulerAdapter.java:153) [jboss-as-clustering-jgroups-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
[JBoss] 	at org.jgroups.protocols.TP.getNumTimerTasks(TP.java:714) [jgroups-2.12.1.Final.jar:]
[JBoss] 	... 11 more
{code}



> JGroups subsystem TimerScedulerAdapter throws UOE when using timer-executor
> ---------------------------------------------------------------------------
>
>                 Key: AS7-1344
>                 URL: https://issues.jboss.org/browse/AS7-1344
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.Final
>            Reporter: Michal Linhard
>            Assignee: Trustin Lee
>
> 07:42:39,535 WARNING [org.jgroups.protocols.UDP] (DiagnosticsHandler,default,perf17-37478) Could not retrieve value of attribute (method) getNumTimerTasks: java.lang.reflect.InvocationTargetException
> [JBoss] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_24]
> [JBoss] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_24]
> [JBoss] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_24]
> [JBoss] 	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_24]
> [JBoss] 	at org.jgroups.stack.Protocol.dumpStats(Protocol.java:272) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at org.jgroups.stack.ProtocolStack.dumpStats(ProtocolStack.java:310) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at org.jgroups.JChannel.dumpStats(JChannel.java:687) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at org.jgroups.JChannel$MyProbeHandler.handleProbe(JChannel.java:2099) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at org.jgroups.protocols.TP$DiagnosticsHandler.handleDiagnosticProbe(TP.java:2165) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at org.jgroups.protocols.TP$DiagnosticsHandler.run(TP.java:2137) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
> [JBoss] Caused by: java.lang.UnsupportedOperationException
> [JBoss] 	at org.jboss.as.clustering.jgroups.TimerSchedulerAdapter.getExecutor(TimerSchedulerAdapter.java:168) [jboss-as-clustering-jgroups-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> [JBoss] 	at org.jboss.as.clustering.jgroups.TimerSchedulerAdapter.size(TimerSchedulerAdapter.java:153) [jboss-as-clustering-jgroups-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> [JBoss] 	at org.jgroups.protocols.TP.getNumTimerTasks(TP.java:714) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	... 11 more
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:25 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1880)
 JMSRedelivered not properly set when a client exits without closing the JMS
 resources (connection, session, consumer)
In-Reply-To: <2095350375.277.1308214523819.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <226875271.67549.1311130465420.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao updated JBMESSAGING-1880:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> JMSRedelivered not properly set when a client exits without closing the JMS resources (connection, session, consumer)
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1880
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1880
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.4.0.SP3.CP12, 1.4.8.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> If a client consumer receives a message and exit without acknowledging it or close the connection/session/consumer object, the message will be cancelled at the server side. When the message is delivered, its JMSRedelivered flag should be true.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:25 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1870)
 ClientSocketWrapper constructors have a redundant call to createStreams()
In-Reply-To: <1435766197.10654.1307498099424.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2099439317.67554.1311130465627.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao updated JBMESSAGING-1870:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> ClientSocketWrapper constructors have a redundant call to createStreams()
> -------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1870
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1870
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP12, 1.4.8.GA
>            Reporter: Ron Sigal
>            Assignee: Yong Hao Gao
>            Priority: Minor
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> org.jboss.jms.client.remoting.ClientSocketWrapper is derived from org.jboss.remoting.transport.socket.ClientSocketWrapper.  The constructors of the former look like
>    public ClientSocketWrapper(Socket socket) throws IOException
>    {
>       super(socket);
>       createStreams(socket, null);
>    }
>    public ClientSocketWrapper(Socket socket, Map metadata, Integer timeout) throws Exception
>    {
>       super(socket, metadata, timeout);
>       createStreams(socket, metadata);
>    }
> and the constructors of the latter look like
>    public ClientSocketWrapper(Socket socket) throws IOException
>    {
>       super(socket);
>       createStreams(socket, null);
>    }
>    public ClientSocketWrapper(Socket socket, Map metadata, Integer timeout) throws Exception
>    {
>       super(socket, timeout);
>       createStreams(socket, metadata);
>    }
> The calls to createStreams() in the JBossMessaging versions of ClientSocketWrapper is redundant.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:25 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1866) Adapt JBM
 tests to new failover model
In-Reply-To: <2021272710.7917.1305686701046.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2048216268.67558.1311130465775.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao updated JBMESSAGING-1866:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> Adapt JBM tests to new failover model
> -------------------------------------
>
>                 Key: JBMESSAGING-1866
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1866
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Tests and Performance
>    Affects Versions: 1.4.0.SP3.CP12, 1.4.8.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> In jbm test suite some tests will fail if the 'keepOldFailoverModel' is set to false. This is because with new model, the failover for a dead node doesn't happen immediately. This affects all tests which expect a failover to happen after a certain timeout.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:25 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1852) Make the
 connection failover retry paramters configurable
In-Reply-To: <585667969.36907.1300516185733.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <280232018.67562.1311130465941.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao updated JBMESSAGING-1852:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> Make the connection failover retry paramters configurable
> ---------------------------------------------------------
>
>                 Key: JBMESSAGING-1852
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1852
>             Project: JBoss Messaging
>          Issue Type: Enhancement
>          Components: JMS Client Manager
>    Affects Versions: 1.4.0.SP3.CP11, 1.4.7.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> Currently if a connection is broken and the client tries to fail over to a new connection, the retry times and intervals are hardcoded. (10 and 2sec resp.)
> Make it configurable can suit some use cases where the server is shutdown and come back later. (with hardcoded retry, the failover may have given up before the server is back).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:26 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1844) JBM throws
 "No expiry queue has been specified so the message will be removed"
In-Reply-To: <1217451594.37497.1296023629693.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1331926386.67568.1311130466164.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao updated JBMESSAGING-1844:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> JBM throws "No expiry queue has been specified so the message will be removed"
> ------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1844
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1844
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Distributed Support
>    Affects Versions: 1.4.0.SP3.CP10
>         Environment: JBoss-EAP-4.3_CP8, JBM-1.4.0-SP3_CP10
>            Reporter: Tyronne Wickramarathne
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15
>
>         Attachments: DistributedTopicExample.java, TopicReceiver.java
>
>
> Clustered JBM throws "No expiry queue has been specified so the message will be removed" WARN message

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:26 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1843) Incorporate
	JBREM-1144
In-Reply-To: <1450854245.31962.1295836069660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1226030916.67572.1311130466289.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao updated JBMESSAGING-1843:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> Incorporate JBREM-1144
> ----------------------
>
>                 Key: JBMESSAGING-1843
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1843
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Remoting
>    Affects Versions: 1.4.0.SP3.CP11, 1.4.7.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>            Priority: Critical
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:26 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1830) Random
 MultipleFailoverTest failures
In-Reply-To: <496312057.5468.1290663779332.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1600284214.67580.1311130466572.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao updated JBMESSAGING-1830:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> Random MultipleFailoverTest failures
> ------------------------------------
>
>                 Key: JBMESSAGING-1830
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1830
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Tests and Performance
>    Affects Versions: 1.4.0.SP3.CP11, 1.4.7.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> The MultipleFailoverTest.testAllKindsOfServerFailures sometimes fails for reason not yet known. So far I have found that the some failoveMap updates didn't get received, so the client didn't failover to the right node.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:26 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1833) Intermittent
 test failure -- MultipleFailoverTest.testAllKindsOfServerFailures()
In-Reply-To: <650585879.170.1292419578321.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <548317731.67575.1311130466365.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao updated JBMESSAGING-1833:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> Intermittent test failure -- MultipleFailoverTest.testAllKindsOfServerFailures()
> --------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1833
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1833
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Tests and Performance
>    Affects Versions: 1.4.0.SP3.CP11, 1.4.7.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> I'm seeing failure in the test, the stack trace:
> 1) testAllKindsOfServerFailures(org.jboss.test.messaging.jms.clustering.MultipleFailoverTest)javax.jms.JMSException: Cannot find a cached connection factory delegate for node -1
> 	at org.jboss.jms.client.container.ClusteringAspect.handleCreateConnectionDelegate(ClusteringAspect.java:217)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:121)
> 	at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeNext(ClientClusteredConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
> 	at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.createConnectionDelegate(ClientClusteredConnectionFactoryDelegate.java)
> 	at org.jboss.jms.client.FailoverCommandCenter.failureDetected(FailoverCommandCenter.java:129)
> 	at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:124)
> 	at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
> 	at org.jboss.jms.client.delegate.ClientSessionDelegate$send_6145266547759487588.invokeNext(ClientSessionDelegate$send_6145266547759487588.java)
> 	at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:172)
> 	at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
> 	at org.jboss.jms.client.delegate.ClientSessionDelegate$send_6145266547759487588.invokeNext(ClientSessionDelegate$send_6145266547759487588.java)
> 	at org.jboss.jms.client.delegate.ClientSessionDelegate.send(ClientSessionDelegate.java)
> 	at org.jboss.jms.client.container.ProducerAspect.handleSend(ProducerAspect.java:276)
> 	at org.jboss.aop.advice.org.jboss.jms.client.container.ProducerAspect40.invoke(ProducerAspect40.java)
> 	at org.jboss.jms.client.delegate.ClientProducerDelegate$send_3961598017717988886.invokeNext(ClientProducerDelegate$send_3961598017717988886.java)
> 	at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:172)
> 	at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
> 	at org.jboss.jms.client.delegate.ClientProducerDelegate$send_3961598017717988886.invokeNext(ClientProducerDelegate$send_3961598017717988886.java)
> 	at org.jboss.jms.client.delegate.ClientProducerDelegate.send(ClientProducerDelegate.java)
> 	at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:165)
> 	at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:208)
> 	at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:146)
> 	at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:137)
> 	at org.jboss.test.messaging.jms.clustering.MultipleFailoverTest.testAllKindsOfServerFailures(MultipleFailoverTest.java:174)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at org.jboss.test.messaging.tools.junit.SelectiveTestRunner.main(SelectiveTestRunner.java:58)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:26 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1826) Removing a
 reference and deleting a message in DB should be wrapped in a single
 transaction in JDBCPersistenceManager
In-Reply-To: <1108601219.33053.1288578414769.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1015805490.67584.1311130466797.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao updated JBMESSAGING-1826:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> Removing a reference and deleting a message in DB should be wrapped in a single transaction in JDBCPersistenceManager 
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1826
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1826
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 1.4.0.SP3.CP10, 1.4.7.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> In JDBCPersistenceManager, when a message is delivered and completed, the message is removed from DB. It includes two deletes in the DB - the reference in JBM_MSG_REF and the message in JBM_MSG. The two deletes are currently done in two separate local transactions as in removeReference() method:
> ...
>          new RemoveReferenceRunner().executeWithRetry();
>          deleteMessage(ref.getMessage().getMessageID());
> ...
> If a server crashes between the two operations, it will leave the tables in an inconsistent state, i.e. ref removed but the message still there. This may result in message stuck, as in this case:
> 1. A server is crashing when a client_ack comes in, the clienk_ack will cause the message to be cleared from the server. If the client_ack processing goes as far as that the removing of reference succeeds but failed to delete the message due to the crashing, the message is left in JBM_MSG table but the corresponding entry in JBM_MSG_REF is gone.
> 2. Eventually the jms client will get ack failure exception. It then expects the messages to be re-delivered after server start-up. But that will never happen. When the server starts up it loads references in JBM_MSG_REF for delivery, but this message's ref is gone.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:27 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1791)
 ConcurrentModificationException at
 org.jboss.jms.server.endpoint.ServerSessionEndpoint.acknowledgeTransactionally
In-Reply-To: <604460415.1267174510332.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <14085440.67601.1311130467329.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao updated JBMESSAGING-1791:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> ConcurrentModificationException at org.jboss.jms.server.endpoint.ServerSessionEndpoint.acknowledgeTransactionally
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1791
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1791
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3
>         Environment: JBoss AS 4.2.3.GA Release (JBossESB 4.7)
> jboss.messaging.jmsVersion=1.1
> jboss.messaging.jmsMajorVersion=1
> jboss.messaging.jmsMinorVersion=1
> jboss.messaging.jmsProviderName=JBoss Messaging
> jboss.messaging.providerVersion=1.4.0.SP3
> jboss.messaging.providerMajorVersion=1
> jboss.messaging.providerMinorVersion=4
> jboss.messaging.providerIncrementingVersion=21
>            Reporter: Cserveny Tamas
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15
>
>         Attachments: server.log
>
>
> Hi, 
> I found a CME in the JBoss-messageing. 
> Test scenario:
> Vanilla JBossESB 4.7 with a simple flow. (file -> queue, bridge queue to another queue, queue -> file)
> I kept this server running on a 2 core system with a load of 10 messages / sec. (ca 3kb messages).
> I received many of these exception during the test. It caused some messages to stuck into the queue, but eventually they were redelivered. (Not after 5s, but after some other messages). They were counted in the 'DeliveringCount', and stayed like that.
> Cheers,
> Tamas
> 2010-02-26 00:00:50,083 ERROR [org.jboss.jms.client.container.ClientConsumer] Failed to deliver message
> javax.jms.JMSException: There is no transaction with id LocalTx[m0r-676r546g-1-2tbmq36g-nq5p47-51zk6a]
>         at org.jboss.jms.tx.ResourceManager.addAck(ResourceManager.java:186)
>         at org.jboss.jms.client.container.SessionAspect.handlePreDeliver(SessionAspect.java:293)
>         at org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect19.invoke(SessionAspect19.java)
>         at org.jboss.jms.client.delegate.ClientSessionDelegate$preDeliver_5548846795541436298.invokeNext(ClientSessionDelegate$preDeliver_5548846795541436298.java)
>         at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
>         at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
>         at org.jboss.jms.client.delegate.ClientSessionDelegate$preDeliver_5548846795541436298.invokeNext(ClientSessionDelegate$preDeliver_5548846795541436298.java)
>         at org.jboss.jms.client.delegate.ClientSessionDelegate.preDeliver(ClientSessionDelegate.java)
>         at org.jboss.jms.client.container.ClientConsumer.callOnMessage(ClientConsumer.java:152)
>         at org.jboss.jms.client.container.ClientConsumer$ListenerRunner.run(ClientConsumer.java:976)
>         at org.jboss.messaging.util.JBMExecutor$TCLExecutor.run(JBMExecutor.java:78)
>         at EDU.oswego.cs.dl.util.concurrent.QueuedExecutor$RunLoop.run(QueuedExecutor.java:89)
>         at java.lang.Thread.run(Thread.java:619)
> 2010-02-26 00:03:22,084 ERROR [org.jboss.messaging.util.ExceptionUtil] ConnectionEndpoint[uip-txvw446g-1-2tbmq36g-nq5p47-51zk6a] sendTransaction [f6r-ghfu546g-1-2tbmq36g-nq5p47-5
> java.util.ConcurrentModificationException
>         at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
>         at java.util.AbstractList$Itr.next(AbstractList.java:343)
>         at org.jboss.jms.server.endpoint.ServerSessionEndpoint.acknowledgeTransactionally(ServerSessionEndpoint.java:1474)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.processTransaction(ServerConnectionEndpoint.java:810)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.java:473)
>         at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$sendTransaction$aop(ConnectionAdvised.java:101)
>         at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
>         at org.jboss.jms.server.container.SecurityAspect.handleSendTransaction(SecurityAspect.java:195)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:26 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1820) Remove
 references to "UsingBatchUpdates" from the *-persistence-service.xml files
 and the documentation.
In-Reply-To: <1965803372.24237.1285366528651.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <738823634.67588.1311130466917.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao updated JBMESSAGING-1820:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> Remove references to "UsingBatchUpdates" from the *-persistence-service.xml files and the documentation.
> --------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1820
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1820
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Configuration and Management, Documentation and Training
>    Affects Versions: 1.4.0.SP3.CP10, 1.4.7.GA
>            Reporter: Justin Bertram
>            Assignee: Justin Bertram
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> This feature was removed in JBoss Messaging 1.4.0.CR2, but the documentation and configuration files were never updated.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:27 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1795) HTTPS
 transport support for JBM
In-Reply-To: <412189554.1269240517743.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <720205957.67595.1311130467129.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao updated JBMESSAGING-1795:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> HTTPS transport support for JBM
> -------------------------------
>
>                 Key: JBMESSAGING-1795
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1795
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: JMS Remoting
>    Affects Versions: 1.4.0.SP3.CP10
>         Environment: JBoss-EAP-4.3_CP7
>            Reporter: Tyronne Wickramarathne
>            Priority: Minor
>             Fix For: 1.4.0.SP3.CP15
>
>
> At present HTTPS transport support isn't available by default for JBM. However, as per Remoting manual, it is possible to configure HTTPS transport for JBM

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:27 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1780) When i change
 the default db schemas of jbm tables the DLQ - if it contains message - run
 in deadlock by the next server restart,
 because it wants to use the default schema instead of the modified db schema
In-Reply-To: <1742553701.1263157710719.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <991035935.67612.1311130467789.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao updated JBMESSAGING-1780:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> When i change the default db schemas of jbm tables the DLQ - if it contains message -  run in deadlock by the next server restart, because it wants to use the default schema instead of the modified db schema 
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1780
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1780
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP09, 1.4.5.GA, 1.4.6.GA
>         Environment: JBoss 5.1.GA+Seam 2.1.1.GA+mysql 5.1
>            Reporter: bb bb
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> At first, I modified the default schema of jbm tables in mysql-persistence-service.xml
> so, I changed the sql properties  JBM_DUAL to  newSchema.JBM_DUAL and so on...
> Everything works fine with the modified schema, until I add a posion message to the dead letter queue.
> Then I want to restart the JBoss server, I get an exception to it run in dead lock, because didn't find the jbm_msg tables (but it would be newSchema.jbm_msg  )

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:27 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1789) setFetchSize
 used in JDBCPersistenceManager with too large value for oracle (200000)
In-Reply-To: <434408512.1265883611705.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2080354354.67608.1311130467654.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1789:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> setFetchSize used in JDBCPersistenceManager with too large value for oracle (200000)
> ------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1789
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1789
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 1.4.5.GA, 1.4.6.GA, 1.4.8.GA
>         Environment: oracle
>            Reporter: Simo Nikula
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> in method loadFromStart (line 984 in 1.4.6) fetchSize is set based on parameter number which is as default 200000.
> setting max rows using setMaxRows with same value would be correct way to limit result set.
> java.sql.SQLException: Bigger type length than Maximum
>         at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:70)
>         at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:133)
>         at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:199)
>         at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:263)
>         at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:271)
>         at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:445)
>         at oracle.jdbc.driver.T4CMAREngine.buffer2Value(T4CMAREngine.java:2253)
>         at oracle.jdbc.driver.T4CMAREngine.unmarshalUB2(T4CMAREngine.java:1101)
>         at oracle.jdbc.driver.T4C8TTIrxh.unmarshalV10(T4C8TTIrxh.java:115)
>         at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:654)
>         at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:194)
>         at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:791)
>         at oracle.jdbc.driver.T4CPreparedStatement.executeMaybeDescribe(T4CPreparedStatement.java:866)
>         at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1186)
>         at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3387)
>         at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3431)
>         at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeQuery(OraclePreparedStatementWrapper.java:1491)
>         at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:342)
>         at org.jboss.messaging.core.impl.JDBCPersistenceManager.loadFromStart(JDBCPersistenceManager.java:988)
>         at org.jboss.messaging.core.impl.PagingChannelSupport.load(PagingChannelSupport.java:211)
>         at org.jboss.jms.server.destination.TopicService.startService(TopicService.java:92)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
>         at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:269)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:28 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1777) Error in
 addMessageIDInHeader while bridging from JBossMQ
In-Reply-To: <2100273285.1261511190714.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1934354082.67617.1311130468026.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1777:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> Error in addMessageIDInHeader while bridging from JBossMQ
> ---------------------------------------------------------
>
>                 Key: JBMESSAGING-1777
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1777
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.3.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Pedro Gontijo
>            Assignee: Yong Hao Gao
>              Labels: JMSXDeliveryCount, addMessageIDInHeader, bridge, jbossmq
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> When addMessageIDInHeader is set to true in a JBossMQ->JBM bridge scenerio the following error occurs:
> WARN  [org.jboss.jms.server.bridge.Bridge] (Thread-27) jboss.messaging:name=MyBridge,service=Bridge Failed to send + acknowledge batch, closing JMS objects
> javax.jms.JMSException: Illegal property name: JMSXDeliveryCount
> 	at org.jboss.mq.SpyMessage.checkProperty(Unknown Source)
> 	at org.jboss.mq.SpyMessage.setObjectProperty(Unknown Source)
> 	at org.jboss.jms.server.bridge.Bridge.addMessageIDInHeader(Bridge.java:1481)
> 	at org.jboss.jms.server.bridge.Bridge.sendMessages(Bridge.java:1391)
> 	at org.jboss.jms.server.bridge.Bridge.sendBatchNonTransacted(Bridge.java:1261)
> 	at org.jboss.jms.server.bridge.Bridge.sendBatch(Bridge.java:1375)
> 	at org.jboss.jms.server.bridge.Bridge.access$1900(Bridge.java:68)
> 	at org.jboss.jms.server.bridge.Bridge$BatchTimeChecker.run(Bridge.java:1638)
> 	at java.lang.Thread.run(Thread.java:595)
> As you can see the error is due JMSX properties, actually, because the addMessageIDInHeader sets then in the MQ message (which is not allowed).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:28 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1771)
 NotSerializableException is thrown from DayCounter class
In-Reply-To: <1502238407.1259219069699.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1450813624.67623.1311130468223.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1771:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> NotSerializableException is thrown from DayCounter class
> --------------------------------------------------------
>
>                 Key: JBMESSAGING-1771
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1771
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.4.0.SP3.CP08
>         Environment: JBoss-SOA-4.3_CP2, JBM-1.4.0.SP3-CP08.patch01
>            Reporter: Tyronne Wickramarathne
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15
>
>
> Even though the MessageCounter class implements Serializable interface as per JBMESSAGING-1430; the NotSerializableException is still thrown when accessing MessageCounter via JMX console. The root cause seems to be the DayCounter class.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:28 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1759) JGroups
 cannot process incoming messages during the method execution
In-Reply-To: <1446880455.1258090265888.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <984786701.67635.1311130468646.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1759:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> JGroups cannot process incoming messages during the method execution
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1759
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1759
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07
>         Environment: JBossMessaging-1.4.0_SP3_CP7
>            Reporter: Tyronne Wickramarathne
>            Assignee: Yong Hao Gao
>            Priority: Critical
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> The GroupMember#viewAccepted() takes 31min on the IncomingPacketHandler thread. The JGroups cannot process incoming messages during this method execution. It's completely blocked and leads the following log and subsequent WARNs.
>  2009-11-11 11:50:12.634 [ViewHandler]  WARN [GMS] - failed to collect all ACKs (1) for view [192.168.1.221:49898|2] [192.168.1.221:49898] after 2000ms, missing ACKs from [192.168.1.221:49898] (received=[]), local_addr=192.168.1.221:49898

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:28 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1761) H2 support
In-Reply-To: <1131873002.1258377209944.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <3128218.67628.1311130468399.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1761:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> H2 support
> ----------
>
>                 Key: JBMESSAGING-1761
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1761
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>    Affects Versions: 1.4.3.GA
>            Reporter: Jesper Pedersen
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> In order for the application server to support H2 as the default database we need the necessary persistence-service.xml files.
> H2: http://www.h2database.com/html/main.html
> Please update Branch_5_x and trunk when released.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:28 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1754) Implement the
 JBossMQ behavior on JBM, when stopDelivery() is invoked via JMX console
In-Reply-To: <1569690620.1256800565753.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2035665949.67640.1311130468808.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1754:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> Implement the JBossMQ behavior on JBM, when stopDelivery() is invoked via JMX console
> -------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1754
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1754
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08
>         Environment: JBoss-EAP-4.3_CP6, JBM-1.4.0-SP3_CP8P1 
>            Reporter: Tyronne Wickramarathne
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> When stopDelivery() is invoked via JMX console for any given MDB, the in process messages are rolled back to their corresponding destination without completing the process. This is however *not* a bug, but the expected behavior in JBM, for this is how it has defined the behavior of stopDelivery(). 
> However on JBossMQ, the in process messages are completed at first, before stopDelivery() is processed. Which means, the call made via stopDelivery() will be kept on hold, until all in process messages are successfully completed. The customers migrating from JBossMQ are seeing this as a compatibility issue, when porting their applications to work on JBM. Hence, would it be possible to accommodate the behavior seen in JBossMQ on JBM please ?
> I have tested this on both JBoss-EAP-4.3_CP6 as well as on JBoss-EAP-4.2_CP7. Both have the same code base for EJB3,JCA but not the JMS provider. Therefore, I'm raising this feature request under JBM.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:28 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1750) Allow
 arbitrary SQL statements for JDBCPersistenceManagerService
In-Reply-To: <620390560.1256620085779.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <362785651.67645.1311130468955.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1750:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> Allow arbitrary SQL statements for JDBCPersistenceManagerService
> ----------------------------------------------------------------
>
>                 Key: JBMESSAGING-1750
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1750
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>    Affects Versions: 1.4.0.SP3.CP08
>            Reporter: Justin Bertram
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> Allow arbitrary SQL statements in the SQLProperties field of org.jboss.messaging.core.jmx.JDBCPersistenceManagerService which will be executed just like all the others (e.g. if CreateTablesOnStartup = "true").  I imagine the statements will need to be named according to some pattern (e.g. "CREATE_*").  
> This functionality will allow greater flexibility for our RDBMS support (e.g. a user could configure support for Oracle TimesTen).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:29 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1744) More
 documented warnings on the usage of JMS selectors
In-Reply-To: <1511528263.1255528386510.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1424610940.67655.1311130469426.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1744:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> More documented warnings on the usage of JMS selectors
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1744
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1744
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Documentation and Training
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.0.SP3.CP09, 1.4.5.GA
>         Environment: EAP 4.3 CP06 / 1.4.0.SP3-CP08.patch01
>            Reporter: Noel Rocher
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> I'm on-site with a customer who is soon going to production.
> They have designed their application using JMS Selectors on distributed queues.
> We all know this is a broken design but my point is that I think this should be explicitely written in the doc.
> Moreover, GSS is talking about an "unsupported configuration" see case # 348290  (https://enterprise.redhat.com/issue-tracker/?module=issues&action=view&tid=348290). 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:29 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1747)
 ClassNotFoundException while consuming a message in a JMS Queue
In-Reply-To: <558530721.1256073185803.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2073208578.67650.1311130469195.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1747:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> ClassNotFoundException while consuming a message in a JMS Queue
> ---------------------------------------------------------------
>
>                 Key: JBMESSAGING-1747
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1747
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Destination Manager
>    Affects Versions: 1.4.1.GA
>         Environment: Jboss version : 5.0.1 GA
>            Reporter: Stephan Lagraulet
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> We have several JMS queues setup on our jboss server.
> We are using spring to handle the messages.
> When several clients simultaneously post some messages in different queues, the consumer doesn't find the class for the task, ending with this stack trace:
> 2009-07-28 17:10:21,089  WARN [SimpleMessageListenerContainer] [] - Execution of JMS message listener failed
> java.lang.RuntimeException: fr.billetel.interfaces.ws.allotement.business.etatventes.request.CodificationsTaskRequest
>         at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
>         at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:247)
>         at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:279)
>         at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1102)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:772)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:415)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
> We debugged the class org.jboss.messaging.util.OrderedExecutorFactory, and it appears that the class doesn't have the right classloader as it reuses a thread previously setup with an other classloader (the application is packaged in different ears while the queues are defined in deploy), ending in this exception.
> For the moment, we patched the code so that the classloader is reloaded for every call, but it does not seem like a good solution on a long term.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:29 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1735) Paging should
 be taken care in Transactions
In-Reply-To: <678531625.1253096603619.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1558160515.67659.1311130469569.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1735:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> Paging should be taken care in Transactions
> -------------------------------------------
>
>                 Key: JBMESSAGING-1735
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1735
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> JBM queues has paging feature to save memory, but in transaction case, messages are stored in the transaction callbacks before it committed to the queue for delivery. So if too many messages are included in one transaction, it may use up memory even paging is turned on.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:29 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1731) Expose the
 JBoss Messaging Cluster partition in JMX
In-Reply-To: <706290811.1251992123859.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1172627557.67665.1311130469853.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1731:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> Expose the JBoss Messaging Cluster partition in JMX
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1731
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1731
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Messaging Core
>    Affects Versions: 1.4.4.GA
>            Reporter: Brad Maxwell
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> Background:
> I have had a request wanting access to the members of the JBoss Messaging Cluster so that they can configure the Recovery plugin without having to hard code hosts in the configuration file.  With the JBoss Messaging Cluster Partition in JMX they would be able to get an accurate list of the members in the Messaging cluster.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:30 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1723) Queue's
 delivering count == -1
In-Reply-To: <773157119.1251244283649.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2027884475.67670.1311130470100.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1723:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> Queue's delivering count == -1
> ------------------------------
>
>                 Key: JBMESSAGING-1723
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1723
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>            Reporter: Ondrej Zizka
>            Assignee: Yong Hao Gao
>            Priority: Minor
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>         Attachments: JMS_delivCount_-1.png
>
>
> Delivery count of a queue is sometimes -1. See the picture attached.
> Seen on EAP 5 CR3, Sun JDK 6 for Linux.
> Steps to reproduce:
> 1) Start a client sending messages,
> 2) Start a client receiving messages,
> 3) Watch the stats. If you're lucky enough, you'll see it being -1.
> I haven't found anything about this in the docs:
> http://labs.jboss.com/file-access/default/members/jbossmessaging/freezone/docs/userguide-1.4.4.GA/html/configuration.html#conf.serverpeer.attributes.messagecounters  ( 6.6.2.1 )

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:30 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1707)
 ConcurrentModificationException in ClientClusteredConnectionFactoryDelegate
In-Reply-To: <410423483.1249981229277.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1800790918.67675.1311130470260.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1707:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> ConcurrentModificationException in ClientClusteredConnectionFactoryDelegate
> ---------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1707
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1707
>             Project: JBoss Messaging
>          Issue Type: Quality Risk
>          Components: JMS Client Manager
>    Affects Versions: 1.4.3.GA
>            Reporter: Pavel Slavicek
>            Assignee: Clebert Suconic
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> I have found ConcurrentModificationException in ClientClusteredConnectionFactoryDelegate.
> Exception in thread "Thread-11" java.util.ConcurrentModificationException
> 	at java.util.WeakHashMap$HashIterator.nextEntry(WeakHashMap.java:784)
> 	at java.util.WeakHashMap$KeyIterator.next(WeakHashMap.java:817)
> 	at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate$FinalizerShutdownHook.run(ClientClusteredConnectionFactoryDelegate.java:414)
> Client:
> client with multiple threads, every thread creates-sends-receives-closes. 
> Problem description:
> Problem is in the ClientClusteredConnectionFactoryDelegate.java in the inner class FinalizerShutdownHook.
> Shutdown hook implementation should to be written as thread safe (see javadoc for addShutdownHook() method). 
> Method run() in the FinalizerShutdownHook class iterates over all elements in the registered delegates 
> but this iteration should be synchronized on the delegates object. 
> Please see http://java.sun.com/javase/6/docs/api/java/util/Collections.html#synchronizedSet%28java.util.Set%29

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:30 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1706) JBoss
 Messaging sometimes causes a HeuristicMixedException
In-Reply-To: <167046771.1249897409362.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <998698092.67684.1311130470694.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1706:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> JBoss Messaging sometimes causes a HeuristicMixedException
> ----------------------------------------------------------
>
>                 Key: JBMESSAGING-1706
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1706
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.4.GA
>            Reporter: Richard Kennard
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>         Attachments: Client_Logs.txt, JBOSS_Server_Logs.txt, remoting-bisocket-service.xml, server.zip
>
>
> I am raising this JIRA to ask the JBoss Messaging Team to take ownership of this issue.
> The issue is that JBM intermittently (ie. when processing large amounts of messages, when bringing up/shutting down nodes in a cluster) throws a HeuristicMixedException. Once it does, that node in the cluster is effectively dead. No more messages get processed. My app has multiple queues, but once one queue on the node fails (say, the e-mail queue) then all queues stop working (say, the reports queues): they all report HeuristicMixedException whenever a messages is sent to them.
> I am using a workaround by having a separate monitoring program that reboots the node whenever it gets stuck in this HeuristicMixedException state.
> The JBoss ESB team have also had to implement a workaround: https://jira.jboss.org/jira/browse/JBESB-2484
> Others on the forum are seeing this too: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241134#4241134
> According to Kevin Conner of the ESB team, Howard worked with them on a workaround: https://jira.jboss.org/jira/browse/JBPAPP-1642, but the issue persists.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:30 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1684) Message
 remain in the queue and do not get dispatched
In-Reply-To: <1603937672.1247553629290.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1908593256.67690.1311130470869.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1684:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> Message remain in the queue and do not get dispatched
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-1684
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1684
>             Project: JBoss Messaging
>          Issue Type: Quality Risk
>          Components: JMS Facade
>    Affects Versions: 1.4.3.GA
>         Environment: SuSe Linux Enterprise Server 10, Java 1.5.0_11, AS 5 with JBoss Messaging - default installation
>            Reporter: Alexander Marktl
>            Assignee: Yong Hao Gao
>            Priority: Minor
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>         Attachments: jms-provider-evaluation.zip
>
>
> I tried to create 10 queues and send 10.000 messages per queue from a single producer per queue to a single consumer per queue. Unfortunately  not all of the messages where delivered, some messages remain in the queues and wait for delivery. The JMX console for example states: 3 messages in the queue, 3 messages pending for delivery. But nothing happens. My receivers don't get these last messages. I don't know if this is a configuration issue or a bug. 
> The queues are named: qname_0 ...qname_n

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:31 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1631) Messages are
 piling up in the queues in clustered environment and not pulled by message
 sucker
In-Reply-To: <30545717.1242929996483.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <926622618.67698.1311130471349.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1631:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1631
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP08
>         Environment: Cluster of a few JBoss 4.2.3 servers with JBM 1.4.2.GA-SP1 or 1.4.0.SP3_CP08 running on x64 windows servers.
> JBoss Remoting 2.5.1 or 2.2.3
> Clustered XA connection factory, clustered queues, both server and client (MDBs) are deployed as one application - identical deployment for all servers in a cluster
>            Reporter: Victor Starenky
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>         Attachments: 1631-test-source.zip, logs-and-config-prod.zip, logs-and-config-test.zip, TestRecommendationSentProcessorMDB.java
>
>
> We have an EJB3 application is running on a cluster of 7 servers. 
> All servers have the same application farmed across them. 
> We have a clustered queue and using clustered connection factory.
> Originally we ran into the bug JBMESSAGING-1456 and while testing the fix ran into a different problem. After the cluster was running for some time (usually overnight with lots of heavy background processing hapenning at that time) we see messages are "piling up" in some queues on some nodes.
> Sympthoms are:
> MessageCount is not zero (rather in the order of hundreeds), DeliveringCount is zero. These nodes have ConsumerCount=0 for the queues experiencing the problem. Message sucker is configured as far as I can tell. Looks like the problem might be related to client and/or server failover leaving some nodes without consumers while sucker not doing it's job (if I understand it correctly). 
> Once we bump the timeout values much higher than they are in the original config files the problem seems to disappear or at least show up much less frequently. Specifically I'm talking about these values:
> messaging-service.xml:
>       <attribute name="FailoverStartTimeout">180000</attribute>
> remoting-bisocket-service.xml:
>                <attribute name="clientLeasePeriod" isParam="true">30000</attribute>
>                <attribute name="validatorPingPeriod" isParam="true">30000</attribute>
>                <attribute name="validatorPingTimeout" isParam="true">20000</attribute>
>                <attribute name="registerCallbackListener">false</attribute>
>                <attribute name="timeout" isParam="true">240000</attribute>
> While this serves as a temporary workaround we don't feel we can rely on JBM in a production clustered environment without having failover working properly.
> This is a big showstopper for us at the moment.
> Attached are the log files from the prod environment of 7 servers with the config files as well as log files from the test environment with just 2 servers (having same issue) and corresponding configs. The logs were produced by the test version of the messaging code with added logging as per JBMESSAGING-1456.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:31 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1621) Provide
 complete message ordering in a clustered environment
In-Reply-To: <16554562.1242110266630.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <888553721.67703.1311130471553.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1621:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> Provide complete message ordering in a clustered environment
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-1621
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1621
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Yusuke Yamamoto
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> While JBMESSAGING-1416 states message ordering feature in a singleton configuration, customer is also requesting a complete message ordering feature which is applicable in a clustered environment.
> Here's the background:
> In the case JMS is used, both performance and scalability are priority.
> There is a conflict between scalable JMS implementation and complete message ordering feature since order aware messages cannot be processed concurrently.
> But order unaware queues should be still processed in parallel for better throughput.
> Additionally, there are some cases that no downtime is acceptable. But HA-Singleton requires certain amount of time to fail-over the service to other node.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:31 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1619) add example
 TCP cluster configuration
In-Reply-To: <8236548.1241645807005.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1887542203.67709.1311130471842.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1619:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> add example TCP cluster configuration
> -------------------------------------
>
>                 Key: JBMESSAGING-1619
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1619
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07
>            Reporter: Dennis Reed
>            Assignee: Tyronne Wickramarathne
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> Add an example TCP cluster configuration (commented out) to all the example *-persistence-service.xml files.
> This will make it easier for users who have issues with UDP multicast to configure it to use TCP clustering.
> (The same thing is being done to all the EAP configurations that don't already include this). 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:32 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1615) Programmatic
 way to check the state of a topic
In-Reply-To: <22443752.1241518126593.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2074589118.67715.1311130472082.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1615:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> Programmatic way to check the state of a topic
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1615
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1615
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>    Affects Versions: 1.4.1.GA
>            Reporter: Colin Mondesir
>            Assignee: Yong Hao Gao
>            Priority: Minor
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> When the deployTopic(String, String) method is called we have found there is a slight delay before the topic is available to create MessageConsumer.
> Is there a programmatic way of checking the state that the topic is in, so that we don't have to wait an arbitrary period of time before creating the Consumer?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:32 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1610) expose
 jbossInternalLifecycle method on jms destination mbeans
In-Reply-To: <27082798.1240932886857.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <770063015.67720.1311130472225.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1610:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> expose jbossInternalLifecycle method on jms destination mbeans
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-1610
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1610
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: AS Integration
>    Affects Versions: 1.4.3.GA
>            Reporter: Emanuel Muckenhuber
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> Currently the Queue and Topic xmbean definitions don't expose the jbossInternalLifecycle(String method). This method is needed that the lifecycle and state changes of a mbean are handled by microcontainer (AS5). Otherwise profileservice cannot determine the current state and a stopped jms destination would be still exposed as running to JON/JOPR.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:32 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1594) Provide
 support for a List of Strings (in StreamMessage) with a size > 64K
In-Reply-To: <19407645.1239259282444.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <739913530.67725.1311130472381.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1594:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> Provide support for a List of Strings (in StreamMessage) with a size > 64K
> --------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1594
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1594
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3
>            Reporter: Colin Mondesir
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> Looking at the code, there is support for 'longstring' for java.lang.String. But that doesn't happen for a List of Strings.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:32 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1517) Malformed
 HTTP POST from Post Office management page in JMX Console
In-Reply-To: <22517353.1235529104697.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1018777776.67730.1311130472668.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1517:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> Malformed HTTP POST from Post Office management page in JMX Console
> -------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1517
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1517
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP03, 1.4.2.GA.SP1
>         Environment: All
>            Reporter: Paul Kaiser
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> When trying to submit changes to the configuration of the Messaging Post Office from the JMX Console interface, the improper quoting of configuration strings results in an improper HTTP POST. This prevents the submission of any updates to the component.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:32 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1513) Database
 maintenance scripts
In-Reply-To: <19858050.1234906484708.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1310208692.67735.1311130472839.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1513:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> Database maintenance scripts
> ----------------------------
>
>                 Key: JBMESSAGING-1513
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1513
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>    Affects Versions: 1.4.2.GA.SP1
>            Reporter: Len DiMaggio
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> Project JIRA for SOA-P platform JIRA: https://jira.jboss.org/jira/browse/SOA-310

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:33 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1491) add support
 for Ingres RDBMS to JBoss Messaging
In-Reply-To: <22555123.1232348524540.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1530609915.67741.1311130473379.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1491:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> add support for Ingres RDBMS to JBoss Messaging
> -----------------------------------------------
>
>                 Key: JBMESSAGING-1491
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1491
>             Project: JBoss Messaging
>          Issue Type: Patch
>    Affects Versions: 1.4.0.SP3.CP06, 2.0.0 Beta1, EAP/SOA-P Integration, 1.4.3.GA, Unscheduled, AS 5.0 Integration
>         Environment: N/A
>            Reporter: murray armfield
>            Assignee: Yong Hao Gao
>            Priority: Minor
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>         Attachments: ingres-persistence-service.newrev.xml, ingres-persistence-service.xml, ingres-persistence-service.xml, ingres.diff, ingresv2.diff
>
>   Original Estimate: 30 minutes
>  Remaining Estimate: 30 minutes
>
> I've been working on JBoss support on Ingres.
> I've written an ingres-persistence-service.xml file for use with Ingres for inclusion as part of JBoss Messaging

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:34 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1490) BridgeService
 should be JAAS aware
In-Reply-To: <12562631.1232152144349.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1426112159.67746.1311130474083.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1490:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> BridgeService should be JAAS aware
> ----------------------------------
>
>                 Key: JBMESSAGING-1490
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1490
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>    Affects Versions: 1.4.2.GA
>         Environment: n/a
>            Reporter: Nicholas Sayer
>            Assignee: Yong Hao Gao
>            Priority: Optional
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> org.jboss.jms.server.bridge.BridgeService currently requires a username and password for the source and destination. It would be better if it could be configured with a JAAS login context name. This would allow username and password information to be set in, for example, a SecureIdentityLoginModule. For example:
>     <application-policy name = "JmsBridgeRealm">
>        <authentication>
>           <login-module code = "org.jboss.resource.security.SecureIdentityLoginModule" flag = "required">
>              <module-option name = "principal">${bridge.user}</module-option>
>              <module-option name = "userName">${bridge.user}</module-option>
>              <module-option name = "password">${bridge.encryptedPassword}</module-option>
>              <module-option name = "ignoreMissigingMCF">true</module-option>
> <!-- it is a separate bug that you must set managedConnectionFactoryName to something regardless of setting ignoreMissingMCF to true -->
>              <module-option name = "managedConnectionFactoryName">jboss.nonexistent:service=NonExistent,name=NonExistent</module-option>
>           </login-module>
>        </authentication>
>     </application-policy>
> There is undoubtedly a better way to accomplish this (probably to pass the JAAS context directly into the JMS connection factory used to vend connections for the bridge), but we're using this as a crude hack for now:
> import java.util.Set;
> import javax.security.auth.Subject;
> import javax.security.auth.login.LoginContext;
> import javax.security.auth.login.LoginException;
> import javax.security.auth.login.CredentialNotFoundException;
> import javax.resource.spi.security.PasswordCredential;
> import org.jboss.jms.server.bridge.BridgeService;
> public class JAASAwareBridgeService extends BridgeService {
>         private String sourceContext, targetContext;
>         public void setSourceLoginContext(String ctxName) { this.sourceContext = ctxName; }
>         public String getSourceLoginContext() { return this.sourceContext; }
>         public void setTargetLoginContext(String ctxName) { this.targetContext = ctxName; }
>         public String getTargetLoginContext() { return this.targetContext; }
>         public void start() throws Exception {
>                 setupSourceCredentials();
>                 setupTargetCredentials();
>                 super.start();
>         }
>         private void setupSourceCredentials() throws LoginException {
>                 PasswordCredential pc = getPasswordCredential(this.sourceContext);
>                 super.setSourceUsername(pc.getUserName());
>                 super.setSourcePassword(new String(pc.getPassword()));
>          }
>         private void setupTargetCredentials() throws LoginException {
>                 PasswordCredential pc = getPasswordCredential(this.targetContext);
>                 super.setTargetUsername(pc.getUserName());
>                 super.setTargetPassword(new String(pc.getPassword()));
>         }
>         private static PasswordCredential getPasswordCredential(String contextName) throws LoginException {
>                 LoginContext ctx = new LoginContext(contextName);
>                 ctx.login();
>                 Subject s = ctx.getSubject();
>                 Set<PasswordCredential> creds = s.getPrivateCredentials(PasswordCredential.class);
>                 if (creds.isEmpty())
>                         throw new CredentialNotFoundException("Login context '" + contextName + "' subject has no PasswordCredential");
>                 return creds.iterator().next(); // get 1st
>         }
> }

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:34 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1478) inconsistent
 test suite performance
In-Reply-To: <25748306.1231170954442.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <88436446.67751.1311130474323.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1478:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> inconsistent test suite performance
> -----------------------------------
>
>                 Key: JBMESSAGING-1478
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1478
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Tests and Performance
>    Affects Versions:  1.4.0.SP3.CP04
>            Reporter: Aleksandar Kostadinov
>            Assignee: Yong Hao Gao
>              Labels: isolation, performance, testsuite
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> I see inconsistent performance running the JBM test suite. Here I have 2 builds on the same physical machine (windows), using local disk storage so environment should be pretty stable.
> The mysql database is shared but I doubt it is the culprit. 
> I run the test suite with the following options:
> property( name: "functional.tests.database", value: dbname )
> property( name: "stress.tests.database", value: dbname )
> property( name: "clustering.tests.database", value: dbname )
> property( name: "test.target", value: "report" )
> property( name: "test.bind.address", value: properties["env.MYTESTIP_1"] )
> property( name: "jboss.messaging.groupname", value: properties["env.BUILD_TAG"])                                                                               
> property( name: "jboss.messaging.datachanneludpaddress", value: properties["env.MCAST_ADDR"] )
> property( name: "jboss.messaging.controlchanneludpaddress", value: properties["env.MCAST_ADDR"] )
> Are there any other options I can add to increase isolation from other processes in the same LAN?
> Would you be able to look at these 2 builds and based on the logs, say why is the first one taking longer and eventually timeout?
> http://hudson.qa.jboss.com/hudson/view/SOA-Release/job/soa-jbm/163/
> http://hudson.qa.jboss.com/hudson/view/SOA-Release/job/soa-jbm/164/

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:34 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1462) Message
 expiration is not correctly managed
In-Reply-To: <32621692.1228481866881.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1735156030.67756.1311130474555.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1462:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> Message expiration is not correctly managed
> -------------------------------------------
>
>                 Key: JBMESSAGING-1462
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1462
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.1.GA
>         Environment: JBAS 5.0GA, JBM 1.4.1GA, persistence on Oracle 10i
>            Reporter: Ivan
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>         Attachments: JBMESSAGING-1462.java
>
>
> 1) A topic is created 
> 2) A durable subscriber is created fro the topic 
> 3) A message is sent on the topic 
> 4) The durable subscriber pulls the message from the topic ( receive() ) but don't ack 
> 5) The durable subscriber is closed, subscriber session.unsuscribe(name) is called but an exception is thrown and then the subsciber session is closed. 
> As result of this a message, expired, with DELIVERY_COUNT = 1 will remain on the database forever. 
> The stacktrace of the exception thrown: 
> java.lang.IllegalStateException: Cannot remove references while deliveries are in progress (Channel 521), there are 1
>         at org.jboss.messaging.core.impl.ChannelSupport.removeAllReferences(ChannelSupport.java:394)
>         at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.internalRemoveBinding(MessagingPostOffice.java:1939)
>         at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.removeBinding(MessagingPostOffice.java:474)
>         at org.jboss.jms.server.endpoint.ServerSessionEndpoint.unsubscribe(ServerSessionEndpoint.java:829)
>         at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$unsubscribe$aop(SessionAdvised.java:135)
>         at org.jboss.jms.server.endpoint.advised.SessionAdvised$unsubscribe_8775578479443985821.invokeTarget(SessionAdvised$unsubscribe_8775578479443985821.java)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
>         at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.jms.server.endpoint.advised.SessionAdvised.unsubscribe(SessionAdvised.java)
>         at org.jboss.jms.wireformat.SessionUnsubscribeRequest.serverInvoke(SessionUnsubscribeRequest.java:74)
>         at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:143)
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
>         at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
>         at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
>         at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:549)
>         at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:35 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1287) SOA-P test
	suite failures
In-Reply-To: <23570323.1210850002522.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <400548393.67766.1311130475466.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1287:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> SOA-P test suite failures
> -------------------------
>
>                 Key: JBMESSAGING-1287
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1287
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP01
>            Reporter: Aleksandar Kostadinov
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> I'm running the JBM test suite against the binaries in the SOA-P Platform 4.2 CP01. I see 4 failures. 
>     * TEST-org.jboss.test.messaging.jms.bridge.BridgeTest-Remote-bisocket.xml.
>     * org.jboss.test.messaging.jms.clustering.MultipleFailoverTest(Clustering).testFailoverFloodTwoServers
>     * org.jboss.test.messaging.jms.clustering.NoFailoverTest(Clustering).testCrashNoFailover
>     * org.jboss.test.messaging.jms.ManifestTest.testManifestEntries
> Failure details in here http://hudson.qa.jboss.com/hudson/job/jboss-soa-platform-JBM-testsuite/73/testReport/
> 3 of the failures are timeout (see console log for BridgeTest). We are running on a 2 CPU DualCore physical machine so system speed should not be an issue. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 22:54:34 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 19 Jul 2011 22:54:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1401) Unverified:
 Restarting a Queue will delete persistent messages in the queue.
In-Reply-To: <1348241.1216341592381.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <521864956.67761.1311130474785.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1401:
--------------------------------------

    Fix Version/s: 1.4.0.SP3.CP15
                       (was: 1.4.0.SP3.CP14)


> Unverified: Restarting a Queue will delete persistent messages in the queue.
> ----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1401
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1401
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.4.0.SP3
>            Reporter: Jay Howell
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP2
>
>
> Restarting a queue in a running server will delete persistent messages out of the database.  This bug was found while troubleshooting a case.  When a customer restarted the queues, they noticed that all of the persistent messages in the database were gone.  I have yet to verify this and will verify as soon as possible.  I wanted to make sure that I didn't forget to put it in.  So at this point this is an unverified bug. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 23:19:23 2011
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 19 Jul 2011 23:19:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-688) Re-enable
 repository browsing on repo.jboss.org/nexus
Message-ID: <1395397665.67778.1311131963607.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Re-enable repository browsing on repo.jboss.org/nexus
-----------------------------------------------------

                 Key: JBBUILD-688
                 URL: https://issues.jboss.org/browse/JBBUILD-688
             Project: JBoss Build System
          Issue Type: Task
          Components: Artifact Repositories
            Reporter: Paul Gier
             Fix For: Build Support 2011


Repository browsing in Nexus was temporarily disabled due to the large number of requests (possibly repo scraping) that were affecting server stability.  These should eventually be re-enabled.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 19 23:23:23 2011
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 19 Jul 2011 23:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-688) Re-enable
 repository browsing on repo.jboss.org/nexus
In-Reply-To: <1395397665.67778.1311131963607.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1684222324.67780.1311132203712.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBBUILD-688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-688:
------------------------------

    Forum Reference: http://community.jboss.org/message/616248


> Re-enable repository browsing on repo.jboss.org/nexus
> -----------------------------------------------------
>
>                 Key: JBBUILD-688
>                 URL: https://issues.jboss.org/browse/JBBUILD-688
>             Project: JBoss Build System
>          Issue Type: Task
>          Components: Artifact Repositories
>            Reporter: Paul Gier
>             Fix For: Build Support 2011
>
>
> Repository browsing in Nexus was temporarily disabled due to the large number of requests (possibly repo scraping) that were affecting server stability.  These should eventually be re-enabled.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 02:58:24 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 20 Jul 2011 02:58:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1343) wsconsume.bat not
	working
In-Reply-To: <347005120.63355.1311087683766.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <362509886.68084.1311145104083.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun reassigned AS7-1343:
--------------------------------

    Assignee: Alessio Soldano  (was: Heiko Braun)


> wsconsume.bat not working
> -------------------------
>
>                 Key: AS7-1343
>                 URL: https://issues.jboss.org/browse/AS7-1343
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Console
>    Affects Versions: 7.0.0.Final
>         Environment: Windows 7
>            Reporter: Mario Antollini
>            Assignee: Alessio Soldano
>             Fix For: Open To Community
>
>
> The file wsconsume.bat under the bin directory does not work.
> The problem is in this line: "-Djava.endorsed.dirs=file:%JBOSS_HOME%/modules/com/sun/xml/bin/main;file:%JBOSS_HOME%/modules/javax/xml/ws/api/main\" ^

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 03:00:24 2011
From: jira-events at lists.jboss.org (Darrin Mison (JIRA))
Date: Wed, 20 Jul 2011 03:00:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1345) sub-deployment
 declared as wrong type in jboss-deployment-structure-1_0.xsd
Message-ID: <1406761219.68087.1311145224122.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

sub-deployment declared as wrong type in jboss-deployment-structure-1_0.xsd
---------------------------------------------------------------------------

                 Key: AS7-1345
                 URL: https://issues.jboss.org/browse/AS7-1345
             Project: Application Server 7
          Issue Type: Bug
    Affects Versions: 7.0.0.Final
            Reporter: Darrin Mison


I suspect that this is a typo in docs/schema/jboss-deployment-structure-1_0.xsd

On line 82, should the type of sub-deployment element be "subDeploymentType" ?

<xsd:element name="sub-deployment" type="deploymentType" minOccurs="0" maxOccurs="unbounded" >

subDeploymentType is declared on line 149 but doesn't seem to be used.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 03:41:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 20 Jul 2011 03:41:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1339) Expose RA config
	properties in DMR
In-Reply-To: <639400179.62523.1311076583633.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <394887743.68122.1311147683801.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated AS7-1339:
-----------------------------

    Priority: Critical  (was: Major)


> Expose RA config properties in DMR
> ----------------------------------
>
>                 Key: AS7-1339
>                 URL: https://issues.jboss.org/browse/AS7-1339
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jeff Zhang
>            Priority: Critical
>             Fix For: 7.1.0.Beta1
>
>
> {noformat}
> The config attributes are not exposed:
> <subsystem xmlns="urn:jboss:domain:resource-adapters:1.0">
> 	[...]         
> 	
>          <config-property name="host">talk.google.com</config-property>
>          <config-property name="port">5222</config-property>
>   
> 	[...]
>    </resource-adapters>
> [standalone at localhost:9999 /] /subsystem=resource-adapters/resource-adapter=xmpp-ra.rar:read-resource
> {
>     "outcome" => "success",
>     "result" => {
>         "archive" => "xmpp-ra.rar",
>         "background-validation" => undefined,
>         "background-validation-minutes" => undefined,
>         "blocking-timeout-wait-millis" => undefined,
>         "connection-definitions" => [{
>             "class-name" => "com/ramphastos/xmpp/jca/XmppManagedConnectionFactory",
>             "jndi-name" => "java:/eis/ra-xmpp",
>             "pool-name" => "XmppFactoryPool",
>             "enabled" => true,
>             "use-java-context" => true,
>             "use-ccm" => true,
>             "max-pool-size" => 100,
>             "min-pool-size" => 10,
>             "pool-prefill" => false,
>             "pool-use-strict-min" => false,
>             "flush-strategy" => "FAILING_CONNECTION_ONLY",
>             "security-application" => true
>         }],
>         "idle-timeout-minutes" => undefined,
>         "max-pool-size" => undefined,
>         "min-pool-size" => undefined,
>         "pool-prefill" => undefined,
>         "pool-use-strict-min" => undefined,
>         "transaction-support" => "NoTransaction",
>         "use-fast-fail" => undefined
>     }
> }
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 03:48:23 2011
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Wed, 20 Jul 2011 03:48:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1343) wsconsume.bat not
	working
In-Reply-To: <347005120.63355.1311087683766.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1376232597.68139.1311148103913.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano reassigned AS7-1343:
------------------------------------

    Assignee: Jim Ma  (was: Alessio Soldano)


Jim can you please verify the issue and fix w/ Windows and forward the pull request if it's fine?

> wsconsume.bat not working
> -------------------------
>
>                 Key: AS7-1343
>                 URL: https://issues.jboss.org/browse/AS7-1343
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Console
>    Affects Versions: 7.0.0.Final
>         Environment: Windows 7
>            Reporter: Mario Antollini
>            Assignee: Jim Ma
>             Fix For: Open To Community
>
>
> The file wsconsume.bat under the bin directory does not work.
> The problem is in this line: "-Djava.endorsed.dirs=file:%JBOSS_HOME%/modules/com/sun/xml/bin/main;file:%JBOSS_HOME%/modules/javax/xml/ws/api/main\" ^

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 03:48:24 2011
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Wed, 20 Jul 2011 03:48:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1343) wsconsume.bat not
	working
In-Reply-To: <347005120.63355.1311087683766.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <969063174.68143.1311148104025.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano updated AS7-1343:
---------------------------------

    Git Pull Request: https://github.com/jbossas/jboss-as/pull/86  (was: https://github.com/jbossas/jboss-as/pull/86)
         Component/s: Web Services
                          (was: Console)


> wsconsume.bat not working
> -------------------------
>
>                 Key: AS7-1343
>                 URL: https://issues.jboss.org/browse/AS7-1343
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>         Environment: Windows 7
>            Reporter: Mario Antollini
>            Assignee: Jim Ma
>             Fix For: Open To Community
>
>
> The file wsconsume.bat under the bin directory does not work.
> The problem is in this line: "-Djava.endorsed.dirs=file:%JBOSS_HOME%/modules/com/sun/xml/bin/main;file:%JBOSS_HOME%/modules/javax/xml/ws/api/main\" ^

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 03:50:24 2011
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Wed, 20 Jul 2011 03:50:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1324) RESTful service
 Servlet configuration fails with ClassCastException
In-Reply-To: <938495355.61579.1311040223621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1452904968.68159.1311148224078.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano reassigned AS7-1324:
------------------------------------

    Assignee: Bill Burke  (was: Alessio Soldano)


Assuming this is a JAX-RS topic, I'm assigning to Bill.

> RESTful service Servlet configuration fails with ClassCastException
> -------------------------------------------------------------------
>
>                 Key: AS7-1324
>                 URL: https://issues.jboss.org/browse/AS7-1324
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>         Environment: Ubuntu 11.04 64 bit, Sun Java 1.6.0_26, JBoss AS 7.0.0.Final 
>            Reporter: Abhijit Sarkar
>            Assignee: Bill Burke
>
> RESTful service fails to deploy with following exception when configured as a Servlet in web.xml. If not configured in web.xml, the service is unavailable on the deployed context path.
> 00:29:32,684 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/movieservicerestful].[MovieServiceRestful]] (http--127.0.0.1-9090-2) Allocate exception for servlet MovieServiceRestful: java.lang.ClassCastException: MovieServiceRestful cannot be cast to javax.servlet.Servlet
> <servlet>
>   <servlet-name>MovieServiceRestful</servlet-name>
>   <servlet-class>MovieServiceRestful</servlet-class>
> </servlet>
> <servlet-mapping>
>   <servlet-name>MovieServiceRestful</servlet-name>
>   <url-pattern>/*</url-pattern>
> </servlet-mapping>

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 03:52:23 2011
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Wed, 20 Jul 2011 03:52:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1343) wsconsume.bat not
	working
In-Reply-To: <347005120.63355.1311087683766.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <201510544.68175.1311148343666.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615337#comment-12615337 ] 

Richard Opalka commented on AS7-1343:
-------------------------------------

Both wsconsume.bat & wsprovide.bat share this problem. So the fix should cover both tools.

> wsconsume.bat not working
> -------------------------
>
>                 Key: AS7-1343
>                 URL: https://issues.jboss.org/browse/AS7-1343
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>         Environment: Windows 7
>            Reporter: Mario Antollini
>            Assignee: Jim Ma
>             Fix For: Open To Community
>
>
> The file wsconsume.bat under the bin directory does not work.
> The problem is in this line: "-Djava.endorsed.dirs=file:%JBOSS_HOME%/modules/com/sun/xml/bin/main;file:%JBOSS_HOME%/modules/javax/xml/ws/api/main\" ^

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 03:59:24 2011
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Wed, 20 Jul 2011 03:59:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-8297) Weld throws error
 No active contexts for scope type javax.enterprise.context.RequestScoped
Message-ID: <1395849517.68207.1311148764923.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBAS-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615341#comment-12615341 ] 

Ales Justin commented on JBAS-8297:
-----------------------------------

>> Ok, assuming this works ok in AS 7, I have no intention to fix this for AS 6.

If this works in AS7, wouldn't this mean we just need to bump the JBossWeb version in AS6?
(or in the worst case patch the one we have, if the new one is incompatible)


> Weld throws error No active contexts for scope type javax.enterprise.context.RequestScoped
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-8297
>                 URL: https://issues.jboss.org/browse/JBAS-8297
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>          Components: Weld/CDI
>         Environment: JBoss 6.0.0.M2, Windows XP SP3
>            Reporter: Marcos Antonio
>            Assignee: Remy Maucherat
>             Fix For: 6.1.0
>
>         Attachments: solicitacoes.zip
>
>
> 2010-04-22 09:55:36,484 WARN  [org.apache.catalina.authenticator.FormAuthenticator] (http-127.0.0.1-8080-1) Unexpected error forwarding to login page: javax.servlet.ServletException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 04:06:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 20 Jul 2011 04:06:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMETA-334) Create a clean
 jboss-ejb3 xsd which matches the implementation
In-Reply-To: <1486809601.5824.1308555023760.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <652795791.68241.1311149183689.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMETA-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf resolved JBMETA-334.
----------------------------------

    Fix Version/s: 7.0.0.Beta6
       Resolution: Done


> Create a clean jboss-ejb3 xsd which matches the implementation
> --------------------------------------------------------------
>
>                 Key: JBMETA-334
>                 URL: https://issues.jboss.org/browse/JBMETA-334
>             Project: JBoss Metadata
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ejb
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>            Priority: Critical
>             Fix For: 7.0.0.Beta6
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 04:23:23 2011
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Wed, 20 Jul 2011 04:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1323) @Resource injection
 on WebServiceContext fails
In-Reply-To: <48156148.61562.1311039863763.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1170130623.68289.1311150203660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615348#comment-12615348 ] 

Alessio Soldano commented on AS7-1323:
--------------------------------------

Please see my message on the forum and follow up there. The rs/resteasy dependencies and errors shown above are not really telling me a lot if the problem is with a jaxws deployment.

> @Resource injection on WebServiceContext fails
> ----------------------------------------------
>
>                 Key: AS7-1323
>                 URL: https://issues.jboss.org/browse/AS7-1323
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>         Environment: Ubuntu 11.04 64 bit, Sun Java 1.6.0_26, JBoss AS 7.0.0.Final
>            Reporter: Abhijit Sarkar
>            Assignee: Alessio Soldano
>
> 00:20:55,004 WARN  [org.jboss.as.ee.component.ResourceInjectionAnnotationParsingProcessor] (MSC service thread 1-4) Can't handle @Resource for ENC name: MovieServiceRestful/wsCtx on class MovieServiceRestful since it's missing a "lookup" (or "mappedName") value and isn't of any known type.
> @WebServiceProvider
> @BindingType(value = HTTPBinding.HTTP_BINDING)
> public class MovieServiceRestful implements Provider<Source> {
>     @Resource
>     protected WebServiceContext wsCtx;
>     ...
> }

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 05:17:25 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 20 Jul 2011 05:17:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1346) Adding RA fails
Message-ID: <1237903510.68346.1311153445173.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Adding RA fails
---------------

                 Key: AS7-1346
                 URL: https://issues.jboss.org/browse/AS7-1346
             Project: Application Server 7
          Issue Type: Bug
          Components: JCA
            Reporter: Heiko Braun
            Assignee: Jesper Pedersen
             Fix For: 7.1.0.Alpha1


Adding a new RA fails:

{noformat}
Request:

[INFO] {
[INFO]     "operation" => "add",
[INFO]     "address" => [
[INFO]         ("subsystem" => "resource-adapters"),
[INFO]         ("resource-adapter" => "xmpp")
[INFO]     ],
[INFO]     "archive" => "xmpp-ra.rar",
[INFO]     "transaction-support" => "NoTransaction",
[INFO]     "connection-definitions" => [{
[INFO]         "class-name" => "com.ramphastos.xmpp.XmppConnectionFactory",
[INFO]         "jndi-name" => "eis/xmpp2",
[INFO]         "pool-name" => "xmpp_Pool"
[INFO]     }]
[INFO] }



Server Log:


11:11:43,826 ERROR [org.jboss.as.controller] (pool-2-thread-2) Operation ("remove") failed - address: ([
    ("subsystem" => "resource-adapters"),
    ("resource-adapter" => "xmpp")
]): java.util.NoSuchElementException: "resource-adapter" => "xmpp"
	at org.jboss.as.controller.registry.BasicResource.requireChild(BasicResource.java:95)
	at org.jboss.as.controller.OperationContextImpl.readModel(OperationContextImpl.java:697)
	at org.jboss.as.connector.subsystems.resourceadapters.RaRemove.execute(RaRemove.java:51)
	at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
	at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
	at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)


{noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 05:19:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 20 Jul 2011 05:19:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1346) Adding RA fails
In-Reply-To: <1237903510.68346.1311153445173.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <303818069.68351.1311153563803.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615357#comment-12615357 ] 

Heiko Braun commented on AS7-1346:
----------------------------------


{noformat}

After tis error the adapter is registred as "xmpp":


[standalone at localhost:9999 /] /subsystem=resource-adapters:read-children-names(child-type=resource-adapter)
{
    "outcome" => "success",
    "result" => ["xmpp"]
}


However when I restart the server it's listed as "xmpp-ra.rar",
which is the archive name. This probably explains the error above.


[standalone at localhost:9999 /] /subsystem=resource-adapters:read-children-names(child-type=resource-adapter)
{
    "outcome" => "success",
    "result" => ["xmpp-ra.rar"]
}
{noformat}





> Adding RA fails
> ---------------
>
>                 Key: AS7-1346
>                 URL: https://issues.jboss.org/browse/AS7-1346
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jesper Pedersen
>             Fix For: 7.1.0.Alpha1
>
>
> Adding a new RA fails:
> {noformat}
> Request:
> [INFO] {
> [INFO]     "operation" => "add",
> [INFO]     "address" => [
> [INFO]         ("subsystem" => "resource-adapters"),
> [INFO]         ("resource-adapter" => "xmpp")
> [INFO]     ],
> [INFO]     "archive" => "xmpp-ra.rar",
> [INFO]     "transaction-support" => "NoTransaction",
> [INFO]     "connection-definitions" => [{
> [INFO]         "class-name" => "com.ramphastos.xmpp.XmppConnectionFactory",
> [INFO]         "jndi-name" => "eis/xmpp2",
> [INFO]         "pool-name" => "xmpp_Pool"
> [INFO]     }]
> [INFO] }
> Server Log:
> 11:11:43,826 ERROR [org.jboss.as.controller] (pool-2-thread-2) Operation ("remove") failed - address: ([
>     ("subsystem" => "resource-adapters"),
>     ("resource-adapter" => "xmpp")
> ]): java.util.NoSuchElementException: "resource-adapter" => "xmpp"
> 	at org.jboss.as.controller.registry.BasicResource.requireChild(BasicResource.java:95)
> 	at org.jboss.as.controller.OperationContextImpl.readModel(OperationContextImpl.java:697)
> 	at org.jboss.as.connector.subsystems.resourceadapters.RaRemove.execute(RaRemove.java:51)
> 	at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
> 	at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
> 	at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 05:44:23 2011
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Wed, 20 Jul 2011 05:44:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1322) Provide service for
 starting/stop a POJO WS endpoint
In-Reply-To: <1951805285.61094.1311016103850.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <585418700.68365.1311155063625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615358#comment-12615358 ] 

Alessio Soldano commented on AS7-1322:
--------------------------------------

Pull request for https://github.com/asoldano/jboss-as/commit/8ad8a5c4e06bbe11801fec373c01d575115a1f72 sent

> Provide service for starting/stop a POJO WS endpoint
> ----------------------------------------------------
>
>                 Key: AS7-1322
>                 URL: https://issues.jboss.org/browse/AS7-1322
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Web Services
>            Reporter: Alessio Soldano
>            Assignee: Alessio Soldano
>             Fix For: 7.1.0.Alpha1
>
>
> We need a service for programatically publishing a WS endpoint on JBoss AS 7 HTTP server. There's recently been a mild interest from the community for this and the functionality would be of great use to projects like XTS requiring publishing of endpoints as part of their subsystem boot.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 05:55:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 20 Jul 2011 05:55:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1347) RA property
 representation is incompatible with DMR model
Message-ID: <1232797559.68368.1311155723631.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

RA property representation is incompatible with DMR model
---------------------------------------------------------

                 Key: AS7-1347
                 URL: https://issues.jboss.org/browse/AS7-1347
             Project: Application Server 7
          Issue Type: Bug
          Components: JCA
            Reporter: Heiko Braun
            Assignee: Jesper Pedersen
            Priority: Critical
             Fix For: 7.1.0.Alpha1


They way the resource adapter properties are currently represented they cannot be described in a DMR operation and thus not be added/created. Take a look at xa-data-source properties to see how it should be done.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 05:59:24 2011
From: jira-events at lists.jboss.org (Jim Ma (JIRA))
Date: Wed, 20 Jul 2011 05:59:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1343) wsconsume.bat not
	working
In-Reply-To: <347005120.63355.1311087683766.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2073316141.68380.1311155964141.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615360#comment-12615360 ] 

Jim Ma commented on AS7-1343:
-----------------------------

I've verified this fix and forward the pull request to the list. Thanks Maas Vdberg !


> wsconsume.bat not working
> -------------------------
>
>                 Key: AS7-1343
>                 URL: https://issues.jboss.org/browse/AS7-1343
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>         Environment: Windows 7
>            Reporter: Mario Antollini
>            Assignee: Jim Ma
>             Fix For: Open To Community
>
>
> The file wsconsume.bat under the bin directory does not work.
> The problem is in this line: "-Djava.endorsed.dirs=file:%JBOSS_HOME%/modules/com/sun/xml/bin/main;file:%JBOSS_HOME%/modules/javax/xml/ws/api/main\" ^

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 06:17:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 20 Jul 2011 06:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1310) Manage resource
 adapters through web console
In-Reply-To: <1962862106.59724.1310983103616.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <842123453.68399.1311157043700.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615363#comment-12615363 ] 

Heiko Braun commented on AS7-1310:
----------------------------------

Current beta is upstream. Waiting on the dependencies to be resolved

> Manage resource adapters through web console
> --------------------------------------------
>
>                 Key: AS7-1310
>                 URL: https://issues.jboss.org/browse/AS7-1310
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Console
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>              Labels: console_prio
>             Fix For: 7.1.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 06:35:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 20 Jul 2011 06:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1347) RA property
 representation is incompatible with DMR model
In-Reply-To: <1232797559.68368.1311155723631.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <30637172.68444.1311158123824.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun reassigned AS7-1347:
--------------------------------

    Assignee: Jeff Zhang  (was: Jesper Pedersen)


> RA property representation is incompatible with DMR model
> ---------------------------------------------------------
>
>                 Key: AS7-1347
>                 URL: https://issues.jboss.org/browse/AS7-1347
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jeff Zhang
>            Priority: Critical
>             Fix For: 7.1.0.Alpha1
>
>
> They way the resource adapter properties are currently represented they cannot be described in a DMR operation and thus not be added/created. Take a look at xa-data-source properties to see how it should be done.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 06:35:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 20 Jul 2011 06:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1346) Adding RA fails
In-Reply-To: <1237903510.68346.1311153445173.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1670616396.68448.1311158123969.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun reassigned AS7-1346:
--------------------------------

    Assignee: Heiko Braun  (was: Jesper Pedersen)


> Adding RA fails
> ---------------
>
>                 Key: AS7-1346
>                 URL: https://issues.jboss.org/browse/AS7-1346
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 7.1.0.Alpha1
>
>
> Adding a new RA fails:
> {noformat}
> Request:
> [INFO] {
> [INFO]     "operation" => "add",
> [INFO]     "address" => [
> [INFO]         ("subsystem" => "resource-adapters"),
> [INFO]         ("resource-adapter" => "xmpp")
> [INFO]     ],
> [INFO]     "archive" => "xmpp-ra.rar",
> [INFO]     "transaction-support" => "NoTransaction",
> [INFO]     "connection-definitions" => [{
> [INFO]         "class-name" => "com.ramphastos.xmpp.XmppConnectionFactory",
> [INFO]         "jndi-name" => "eis/xmpp2",
> [INFO]         "pool-name" => "xmpp_Pool"
> [INFO]     }]
> [INFO] }
> Server Log:
> 11:11:43,826 ERROR [org.jboss.as.controller] (pool-2-thread-2) Operation ("remove") failed - address: ([
>     ("subsystem" => "resource-adapters"),
>     ("resource-adapter" => "xmpp")
> ]): java.util.NoSuchElementException: "resource-adapter" => "xmpp"
> 	at org.jboss.as.controller.registry.BasicResource.requireChild(BasicResource.java:95)
> 	at org.jboss.as.controller.OperationContextImpl.readModel(OperationContextImpl.java:697)
> 	at org.jboss.as.connector.subsystems.resourceadapters.RaRemove.execute(RaRemove.java:51)
> 	at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
> 	at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
> 	at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 06:37:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 20 Jul 2011 06:37:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1346) Adding RA fails
In-Reply-To: <1237903510.68346.1311153445173.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1986124350.68453.1311158243703.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun reassigned AS7-1346:
--------------------------------

    Assignee: Jeff Zhang  (was: Heiko Braun)


> Adding RA fails
> ---------------
>
>                 Key: AS7-1346
>                 URL: https://issues.jboss.org/browse/AS7-1346
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.Alpha1
>
>
> Adding a new RA fails:
> {noformat}
> Request:
> [INFO] {
> [INFO]     "operation" => "add",
> [INFO]     "address" => [
> [INFO]         ("subsystem" => "resource-adapters"),
> [INFO]         ("resource-adapter" => "xmpp")
> [INFO]     ],
> [INFO]     "archive" => "xmpp-ra.rar",
> [INFO]     "transaction-support" => "NoTransaction",
> [INFO]     "connection-definitions" => [{
> [INFO]         "class-name" => "com.ramphastos.xmpp.XmppConnectionFactory",
> [INFO]         "jndi-name" => "eis/xmpp2",
> [INFO]         "pool-name" => "xmpp_Pool"
> [INFO]     }]
> [INFO] }
> Server Log:
> 11:11:43,826 ERROR [org.jboss.as.controller] (pool-2-thread-2) Operation ("remove") failed - address: ([
>     ("subsystem" => "resource-adapters"),
>     ("resource-adapter" => "xmpp")
> ]): java.util.NoSuchElementException: "resource-adapter" => "xmpp"
> 	at org.jboss.as.controller.registry.BasicResource.requireChild(BasicResource.java:95)
> 	at org.jboss.as.controller.OperationContextImpl.readModel(OperationContextImpl.java:697)
> 	at org.jboss.as.connector.subsystems.resourceadapters.RaRemove.execute(RaRemove.java:51)
> 	at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
> 	at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
> 	at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 06:39:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Wed, 20 Jul 2011 06:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (AS7-1314)
 LifecycleAnnotationParsingProcessor creates EEClassDescriptions for every
 class, not just component classes
In-Reply-To: <1361011650.59918.1310988096006.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <493779123.68459.1311158363649.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reopened AS7-1314:
---------------------------------



This does not appear to be fixed, as the exception could occur when configuring the EEClassConfiguration, not at load time

> LifecycleAnnotationParsingProcessor creates EEClassDescriptions for every class, not just component classes 
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1314
>                 URL: https://issues.jboss.org/browse/AS7-1314
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 7.0.0.Final
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 7.0.1.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 07:09:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Wed, 20 Jul 2011 07:09:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1348) Weld breaks RichFaces
	4
Message-ID: <961263785.68524.1311160163613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Weld breaks RichFaces 4
-----------------------

                 Key: AS7-1348
                 URL: https://issues.jboss.org/browse/AS7-1348
             Project: Application Server 7
          Issue Type: Bug
          Components: CDI / Weld
    Affects Versions: 7.0.0.Final
         Environment: Jenkins build 1402
            Reporter: Juergen Zimmermann
            Assignee: Stuart Douglas


I'm migrating an EAR from JBoss 6 to 7. The Web module is based on RichFaces 4 and Weld. However, I'm getting the stacktrace below. I'll attach a testcase.

Stacktrace:
javax.el.ELException: Cannot convert testcase.PasswordGroup of type class java.lang.String to class [Ljava.lang.Class;
	at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:470)
	at org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:46)
	at org.jboss.weld.util.el.ForwardingExpressionFactory.coerceToType(ForwardingExpressionFactory.java:37)
	at com.sun.faces.facelets.tag.BeanPropertyTagRule$LiteralPropertyMetadata.applyMetadata(BeanPropertyTagRule.java:88)
	at com.sun.faces.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:81)
	at javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:129)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:102)
	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.setAttributes(BehaviorsAddingComponentHandlerWrapper.java:115)
	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.doNewComponentActions(ComponentTagHandlerDelegateImpl.java:402)
	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:159)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
	at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
	at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:82)
	at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:152)
	at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:744)
	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:100)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:313)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
	at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893)
	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
	at java.lang.Thread.run(Thread.java:662)


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 07:16:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Wed, 20 Jul 2011 07:16:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1348) Weld breaks
	RichFaces 4
In-Reply-To: <961263785.68524.1311160163613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <52038847.68533.1311160583961.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615373#comment-12615373 ] 

Stuart Douglas commented on AS7-1348:
-------------------------------------

What makes you say this has anything to do with weld, it looks like a JSF converter issue

> Weld breaks RichFaces 4
> -----------------------
>
>                 Key: AS7-1348
>                 URL: https://issues.jboss.org/browse/AS7-1348
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 7.0.0.Final
>         Environment: Jenkins build 1402
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>         Attachments: testcase-src.zip, testcase.ear.zip
>
>
> I'm migrating an EAR from JBoss 6 to 7. The Web module is based on RichFaces 4 and Weld. However, I'm getting the stacktrace below. I'll attach a testcase.
> Stacktrace:
> javax.el.ELException: Cannot convert testcase.PasswordGroup of type class java.lang.String to class [Ljava.lang.Class;
> 	at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:470)
> 	at org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:46)
> 	at org.jboss.weld.util.el.ForwardingExpressionFactory.coerceToType(ForwardingExpressionFactory.java:37)
> 	at com.sun.faces.facelets.tag.BeanPropertyTagRule$LiteralPropertyMetadata.applyMetadata(BeanPropertyTagRule.java:88)
> 	at com.sun.faces.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:81)
> 	at javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:129)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:102)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.setAttributes(BehaviorsAddingComponentHandlerWrapper.java:115)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.doNewComponentActions(ComponentTagHandlerDelegateImpl.java:402)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:159)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:82)
> 	at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:152)
> 	at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:744)
> 	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:100)
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> 	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:313)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:662)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 07:16:24 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Wed, 20 Jul 2011 07:16:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1348) Weld breaks RichFaces
	4
In-Reply-To: <961263785.68524.1311160163613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1888721191.68536.1311160584056.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juergen Zimmermann updated AS7-1348:
------------------------------------

    Attachment: testcase-src.zip
                testcase.ear.zip


* testcase.ear.zip contains the exploded EAR as a ZIP file
* testcase-src.zip contains the sources: testcase for the EAR itself, testcaseEJB for a minimal EJB project, testcaseUtil for a minimal Utility project (i.e. a JAR for <ear>/lib), and testcaseWeb for a minimal Web modul.

Just invoke http://localhost:8080/testcase to produce the stacktrace.

index.xhtml is refering to a validation group "testcase.PasswordGroup" which is a Java interface according to Bean Validation. This validation group is used inside the tag <rich:graphValidator ... groups="testcase.PasswordGroup">

> Weld breaks RichFaces 4
> -----------------------
>
>                 Key: AS7-1348
>                 URL: https://issues.jboss.org/browse/AS7-1348
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 7.0.0.Final
>         Environment: Jenkins build 1402
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>         Attachments: testcase-src.zip, testcase.ear.zip
>
>
> I'm migrating an EAR from JBoss 6 to 7. The Web module is based on RichFaces 4 and Weld. However, I'm getting the stacktrace below. I'll attach a testcase.
> Stacktrace:
> javax.el.ELException: Cannot convert testcase.PasswordGroup of type class java.lang.String to class [Ljava.lang.Class;
> 	at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:470)
> 	at org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:46)
> 	at org.jboss.weld.util.el.ForwardingExpressionFactory.coerceToType(ForwardingExpressionFactory.java:37)
> 	at com.sun.faces.facelets.tag.BeanPropertyTagRule$LiteralPropertyMetadata.applyMetadata(BeanPropertyTagRule.java:88)
> 	at com.sun.faces.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:81)
> 	at javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:129)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:102)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.setAttributes(BehaviorsAddingComponentHandlerWrapper.java:115)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.doNewComponentActions(ComponentTagHandlerDelegateImpl.java:402)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:159)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:82)
> 	at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:152)
> 	at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:744)
> 	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:100)
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> 	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:313)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:662)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 07:20:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Wed, 20 Jul 2011 07:20:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1348) Weld breaks
	RichFaces 4
In-Reply-To: <961263785.68524.1311160163613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <9115397.68548.1311160823919.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615375#comment-12615375 ] 

Juergen Zimmermann commented on AS7-1348:
-----------------------------------------

Stuart, it is working fine with JBoss 6 which has the same JSF implemenation (Mojarra). Therefore, I'm assuming that the issue is not related to Mojarra. In the stacktrace I'm seeing org.jboss.weld.util.el.ForwardingExpressionFactory.coerceToType() immediately before Apache's EL is invoked. Could it be that the EL is invoked with wrong parameters?

> Weld breaks RichFaces 4
> -----------------------
>
>                 Key: AS7-1348
>                 URL: https://issues.jboss.org/browse/AS7-1348
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 7.0.0.Final
>         Environment: Jenkins build 1402
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>         Attachments: testcase-src.zip, testcase.ear.zip
>
>
> I'm migrating an EAR from JBoss 6 to 7. The Web module is based on RichFaces 4 and Weld. However, I'm getting the stacktrace below. I'll attach a testcase.
> Stacktrace:
> javax.el.ELException: Cannot convert testcase.PasswordGroup of type class java.lang.String to class [Ljava.lang.Class;
> 	at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:470)
> 	at org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:46)
> 	at org.jboss.weld.util.el.ForwardingExpressionFactory.coerceToType(ForwardingExpressionFactory.java:37)
> 	at com.sun.faces.facelets.tag.BeanPropertyTagRule$LiteralPropertyMetadata.applyMetadata(BeanPropertyTagRule.java:88)
> 	at com.sun.faces.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:81)
> 	at javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:129)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:102)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.setAttributes(BehaviorsAddingComponentHandlerWrapper.java:115)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.doNewComponentActions(ComponentTagHandlerDelegateImpl.java:402)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:159)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:82)
> 	at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:152)
> 	at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:744)
> 	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:100)
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> 	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:313)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:662)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 07:22:23 2011
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 20 Jul 2011 07:22:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1349) JAX-RS sub resources
	broken
Message-ID: <205889520.68555.1311160943630.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

JAX-RS sub resources broken
---------------------------

                 Key: AS7-1349
                 URL: https://issues.jboss.org/browse/AS7-1349
             Project: Application Server 7
          Issue Type: Bug
          Components: Web Services
    Affects Versions: 7.0.0.Final
            Reporter: Jozef Hartinger
            Assignee: Stuart Douglas
            Priority: Critical
             Fix For: 7.0.1.Final


Having a root resource class

@Path("person")
public class PeopleResource {

    @Path("{name}")
    public PersonResource findPerson(@PathParam("name") String name)
    {
        return new PersonResource(name);
    }
}

and a sub resource class

public class PersonResource {

    private String name;

    public PersonResource(String name) {
        this.name = name;
    }

    @GET
    public String getName()
    {
        return name;
    }
    
    @GET
    @Path("/address")
    public String getClassName()
    {
        return name + "'s address is unknown.";
    }
}

The application fails with the following exception. Seems like during scanning the subresource is identified as a root resource (although it is not a root resource). Subsequently, RESTEasy's validation fails.

javax.servlet.ServletException: Servlet.init() for servlet org.jboss.resteasy.cdi.test.MyApplication threw exception
	org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
	org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
	org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
	org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667)
	org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951)
	java.lang.Thread.run(Thread.java:662)

root cause

java.lang.RuntimeException: Class is not a root resource.  It, or one of its interfaces must be annotated with @Path: org.jboss.resteasy.cdi.test.Subresource implements:  java.io.Serializable
	org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:104)
	org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:83)
	org.jboss.resteasy.core.ResourceMethodRegistry.addPerRequestResource(ResourceMethodRegistry.java:72)
	org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:367)
	org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:225)
	org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:67)
	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
	org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
	org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
	org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
	org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667)
	org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951)
	java.lang.Thread.run(Thread.java:662)



--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 07:24:24 2011
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 20 Jul 2011 07:24:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1349) JAX-RS sub
	resources broken
In-Reply-To: <205889520.68555.1311160943630.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1068776147.68574.1311161064418.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615378#comment-12615378 ] 

Jozef Hartinger commented on AS7-1349:
--------------------------------------

Testcase for the issue https://github.com/jharting/jboss-as/tree/AS7-1349-testcase.

> JAX-RS sub resources broken
> ---------------------------
>
>                 Key: AS7-1349
>                 URL: https://issues.jboss.org/browse/AS7-1349
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>            Reporter: Jozef Hartinger
>            Assignee: Stuart Douglas
>            Priority: Critical
>             Fix For: 7.0.1.Final
>
>
> Having a root resource class
> @Path("person")
> public class PeopleResource {
>     @Path("{name}")
>     public PersonResource findPerson(@PathParam("name") String name)
>     {
>         return new PersonResource(name);
>     }
> }
> and a sub resource class
> public class PersonResource {
>     private String name;
>     public PersonResource(String name) {
>         this.name = name;
>     }
>     @GET
>     public String getName()
>     {
>         return name;
>     }
>     
>     @GET
>     @Path("/address")
>     public String getClassName()
>     {
>         return name + "'s address is unknown.";
>     }
> }
> The application fails with the following exception. Seems like during scanning the subresource is identified as a root resource (although it is not a root resource). Subsequently, RESTEasy's validation fails.
> javax.servlet.ServletException: Servlet.init() for servlet org.jboss.resteasy.cdi.test.MyApplication threw exception
> 	org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
> 	org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
> 	org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> 	org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667)
> 	org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951)
> 	java.lang.Thread.run(Thread.java:662)
> root cause
> java.lang.RuntimeException: Class is not a root resource.  It, or one of its interfaces must be annotated with @Path: org.jboss.resteasy.cdi.test.Subresource implements:  java.io.Serializable
> 	org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:104)
> 	org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:83)
> 	org.jboss.resteasy.core.ResourceMethodRegistry.addPerRequestResource(ResourceMethodRegistry.java:72)
> 	org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:367)
> 	org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:225)
> 	org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:67)
> 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
> 	org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
> 	org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
> 	org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> 	org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667)
> 	org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951)
> 	java.lang.Thread.run(Thread.java:662)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 07:26:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 20 Jul 2011 07:26:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-738) Provide a JNDI View
 operation, similar to AS6
In-Reply-To: <1688147340.43381.1305040998290.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1385909050.68581.1311161183703.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun reassigned AS7-738:
-------------------------------

    Assignee: Heiko Braun


> Provide a JNDI View operation, similar to AS6
> ---------------------------------------------
>
>                 Key: AS7-738
>                 URL: https://issues.jboss.org/browse/AS7-738
>             Project: Application Server 7
>          Issue Type: Enhancement
>          Components: Domain Management, Naming
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>              Labels: console_prio
>             Fix For: 7.1.0.Alpha1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 07:50:24 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 20 Jul 2011 07:50:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMETA-335) Implement
	message-driven parsing
Message-ID: <1212037981.68635.1311162624097.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Implement message-driven parsing
--------------------------------

                 Key: JBMETA-335
                 URL: https://issues.jboss.org/browse/JBMETA-335
             Project: JBoss Metadata
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: ejb
    Affects Versions: 7.0.0.Beta6
            Reporter: Carlo de Wolf
            Assignee: Carlo de Wolf
            Priority: Critical




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 07:52:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Wed, 20 Jul 2011 07:52:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1348) Weld breaks
	RichFaces 4
In-Reply-To: <961263785.68524.1311160163613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1254389506.68639.1311162743853.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615386#comment-12615386 ] 

Stuart Douglas commented on AS7-1348:
-------------------------------------

org.jboss.weld.util.el.ForwardingExpressionFactory.coerceToType()  simply delegates to the underlying implementation. I don't think the actual version of Mojarra is the same between AS6 and AS7 (although I have not actually checked).

> Weld breaks RichFaces 4
> -----------------------
>
>                 Key: AS7-1348
>                 URL: https://issues.jboss.org/browse/AS7-1348
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 7.0.0.Final
>         Environment: Jenkins build 1402
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>         Attachments: testcase-src.zip, testcase.ear.zip
>
>
> I'm migrating an EAR from JBoss 6 to 7. The Web module is based on RichFaces 4 and Weld. However, I'm getting the stacktrace below. I'll attach a testcase.
> Stacktrace:
> javax.el.ELException: Cannot convert testcase.PasswordGroup of type class java.lang.String to class [Ljava.lang.Class;
> 	at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:470)
> 	at org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:46)
> 	at org.jboss.weld.util.el.ForwardingExpressionFactory.coerceToType(ForwardingExpressionFactory.java:37)
> 	at com.sun.faces.facelets.tag.BeanPropertyTagRule$LiteralPropertyMetadata.applyMetadata(BeanPropertyTagRule.java:88)
> 	at com.sun.faces.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:81)
> 	at javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:129)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:102)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.setAttributes(BehaviorsAddingComponentHandlerWrapper.java:115)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.doNewComponentActions(ComponentTagHandlerDelegateImpl.java:402)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:159)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:82)
> 	at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:152)
> 	at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:744)
> 	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:100)
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> 	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:313)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:662)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 08:00:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Wed, 20 Jul 2011 08:00:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1348) Weld breaks
	RichFaces 4
In-Reply-To: <961263785.68524.1311160163613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1827128049.68672.1311163223702.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615388#comment-12615388 ] 

Juergen Zimmermann commented on AS7-1348:
-----------------------------------------

I checked the Mojarra versions:
* My JBoss 6 has Mojarra 2.0.4-b09 (upgraded manually from 2.0.3)
* JBoss 7 has a patched version of Mojarra 2.0.4: 2.0.4-b09-jbossorg-4

So do you think that the patched Mojarra version is causing the regression?

> Weld breaks RichFaces 4
> -----------------------
>
>                 Key: AS7-1348
>                 URL: https://issues.jboss.org/browse/AS7-1348
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 7.0.0.Final
>         Environment: Jenkins build 1402
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>         Attachments: testcase-src.zip, testcase.ear.zip
>
>
> I'm migrating an EAR from JBoss 6 to 7. The Web module is based on RichFaces 4 and Weld. However, I'm getting the stacktrace below. I'll attach a testcase.
> Stacktrace:
> javax.el.ELException: Cannot convert testcase.PasswordGroup of type class java.lang.String to class [Ljava.lang.Class;
> 	at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:470)
> 	at org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:46)
> 	at org.jboss.weld.util.el.ForwardingExpressionFactory.coerceToType(ForwardingExpressionFactory.java:37)
> 	at com.sun.faces.facelets.tag.BeanPropertyTagRule$LiteralPropertyMetadata.applyMetadata(BeanPropertyTagRule.java:88)
> 	at com.sun.faces.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:81)
> 	at javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:129)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:102)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.setAttributes(BehaviorsAddingComponentHandlerWrapper.java:115)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.doNewComponentActions(ComponentTagHandlerDelegateImpl.java:402)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:159)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:82)
> 	at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:152)
> 	at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:744)
> 	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:100)
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> 	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:313)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:662)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 08:04:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Wed, 20 Jul 2011 08:04:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1348) Weld breaks
	RichFaces 4
In-Reply-To: <961263785.68524.1311160163613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <648610865.68692.1311163463966.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615389#comment-12615389 ] 

Juergen Zimmermann commented on AS7-1348:
-----------------------------------------

Another guess: does JBoss 6 have its own implementation of the expression language EL, and is not using the Apache implementation?

> Weld breaks RichFaces 4
> -----------------------
>
>                 Key: AS7-1348
>                 URL: https://issues.jboss.org/browse/AS7-1348
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 7.0.0.Final
>         Environment: Jenkins build 1402
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>         Attachments: testcase-src.zip, testcase.ear.zip
>
>
> I'm migrating an EAR from JBoss 6 to 7. The Web module is based on RichFaces 4 and Weld. However, I'm getting the stacktrace below. I'll attach a testcase.
> Stacktrace:
> javax.el.ELException: Cannot convert testcase.PasswordGroup of type class java.lang.String to class [Ljava.lang.Class;
> 	at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:470)
> 	at org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:46)
> 	at org.jboss.weld.util.el.ForwardingExpressionFactory.coerceToType(ForwardingExpressionFactory.java:37)
> 	at com.sun.faces.facelets.tag.BeanPropertyTagRule$LiteralPropertyMetadata.applyMetadata(BeanPropertyTagRule.java:88)
> 	at com.sun.faces.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:81)
> 	at javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:129)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:102)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.setAttributes(BehaviorsAddingComponentHandlerWrapper.java:115)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.doNewComponentActions(ComponentTagHandlerDelegateImpl.java:402)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:159)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:82)
> 	at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:152)
> 	at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:744)
> 	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:100)
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> 	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:313)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:662)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 08:26:23 2011
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Wed, 20 Jul 2011 08:26:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1350) Add management
 operations to assign/unassign handlers from loggers and async handlers.
Message-ID: <788349166.68808.1311164783691.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Add management operations to assign/unassign handlers from loggers and async handlers.
--------------------------------------------------------------------------------------

                 Key: AS7-1350
                 URL: https://issues.jboss.org/browse/AS7-1350
             Project: Application Server 7
          Issue Type: Feature Request
    Affects Versions: 7.0.0.Final
            Reporter: Stan Silvert
            Assignee: Stan Silvert
             Fix For: 7.1.0.Alpha1


Proposed new management operations:

For Async Handler:
assign-subhandler
unassign-subhandler

For Root Logger:
root-logger-assign-handler
root-logger-unassign-handler

For other Loggers:
assign-handler
unassign-handler

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 09:07:25 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 20 Jul 2011 09:07:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-8786) JBoss unpacks all
 jars from WEB-INF\lib of war file
In-Reply-To: <576153813.40493.1294234097935.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <268599444.69014.1311167245126.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBAS-8786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615414#comment-12615414 ] 

jaikiran pai commented on JBAS-8786:
------------------------------------

This is now fixed in r111792. Those of you watching or who voted for this issue, please use that nightly build containing this fix as explained here http://community.jboss.org/thread/161386 and give it a try. Let us know how it goes.


> JBoss unpacks all jars from WEB-INF\lib of war file
> ---------------------------------------------------
>
>                 Key: JBAS-8786
>                 URL: https://issues.jboss.org/browse/JBAS-8786
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers, Web (Tomcat) service
>    Affects Versions: 6.0.0.Final
>         Environment: Windows XP x32
>            Reporter: Maxym Pendyshchuk
>            Assignee: jaikiran pai
>            Priority: Blocker
>             Fix For: 6.1.0
>
>         Attachments: jarbomb.zip, JBAS-8786.patch, jboss-as-server.jar
>
>
> while starting JBoss AS it unpacks all jar files, which are located in WEB-INF/lib folder of each my war file. It means that in tmp folder mostly I see folder with jar file, and folder with its content. E.g. jackrabbit-server.war contains library asm-3.1.jar, then in tmp folder I see the following folders with files:
> asm-3.1.jar-83dc35ead0d41d41/asm-3.1.jar
> asm-3.1.jar-2a48f1c13ec7f25d/contents/"unpacked asm-3.1.jar"
> actually when I repack jackrabbit-server.war to jackrabbit-server.ear which contains jackrabbit-server.war and moved all its libraries to jackrabbit-server.ear/lib then I still see two folders in tmp:
> asm-3.1.jar-215a36131ebb088e/asm-3.1.jar
> asm-3.1.jar-14695f157664f00/contents/
> but in this case last folder is empty. So it still creates two folders, but does not unpack my library. Also I use exploded deployment so the question is only about jar files, not unpacking ear/war.
> the problem is that it slows down application server booting (when I repack all my war files as ear and moved war libraries to ear/lib folder then I save 2+ minutes at JBoss 6 booting...). If it is done deliberately (so it improves some performance at runtime), then would be nice to have a configuration option, so during development I can save time to boot my local JBoss AS

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 09:07:26 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 20 Jul 2011 09:07:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-8786) JBoss unpacks all
 jars from WEB-INF\lib of war file
In-Reply-To: <576153813.40493.1294234097935.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <459706791.69047.1311167246851.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBAS-8786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved JBAS-8786.
--------------------------------

    Resolution: Done


> JBoss unpacks all jars from WEB-INF\lib of war file
> ---------------------------------------------------
>
>                 Key: JBAS-8786
>                 URL: https://issues.jboss.org/browse/JBAS-8786
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers, Web (Tomcat) service
>    Affects Versions: 6.0.0.Final
>         Environment: Windows XP x32
>            Reporter: Maxym Pendyshchuk
>            Assignee: jaikiran pai
>            Priority: Blocker
>             Fix For: 6.1.0
>
>         Attachments: jarbomb.zip, JBAS-8786.patch, jboss-as-server.jar
>
>
> while starting JBoss AS it unpacks all jar files, which are located in WEB-INF/lib folder of each my war file. It means that in tmp folder mostly I see folder with jar file, and folder with its content. E.g. jackrabbit-server.war contains library asm-3.1.jar, then in tmp folder I see the following folders with files:
> asm-3.1.jar-83dc35ead0d41d41/asm-3.1.jar
> asm-3.1.jar-2a48f1c13ec7f25d/contents/"unpacked asm-3.1.jar"
> actually when I repack jackrabbit-server.war to jackrabbit-server.ear which contains jackrabbit-server.war and moved all its libraries to jackrabbit-server.ear/lib then I still see two folders in tmp:
> asm-3.1.jar-215a36131ebb088e/asm-3.1.jar
> asm-3.1.jar-14695f157664f00/contents/
> but in this case last folder is empty. So it still creates two folders, but does not unpack my library. Also I use exploded deployment so the question is only about jar files, not unpacking ear/war.
> the problem is that it slows down application server booting (when I repack all my war files as ear and moved war libraries to ear/lib folder then I save 2+ minutes at JBoss 6 booting...). If it is done deliberately (so it improves some performance at runtime), then would be nice to have a configuration option, so during development I can save time to boot my local JBoss AS

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 09:11:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 20 Jul 2011 09:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-9150) JRuby war
 deployment error on JBoss AS
In-Reply-To: <1569181662.1070.1301086057821.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1308736606.69094.1311167483936.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBAS-9150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615416#comment-12615416 ] 

jaikiran pai commented on JBAS-9150:
------------------------------------

If this isn't reproducible then let's close this as "Not Reproducible", so that we don't have to track this for 6.1.0.


> JRuby war deployment error on JBoss AS
> --------------------------------------
>
>                 Key: JBAS-9150
>                 URL: https://issues.jboss.org/browse/JBAS-9150
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Abin Shahab
>            Assignee: Daniel Bevenius
>              Labels: open_to_community
>             Fix For: 6.1.0, Open To Community
>
>         Attachments: hello_missing_libs.war, jruby-core-1.6.1.jar, jruby-rack-1.0.8.jar
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 09:21:24 2011
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Wed, 20 Jul 2011 09:21:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1283) Cookie-Based Sessions
	Broken
In-Reply-To: <125463836.53501.1310646803618.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1152105346.69148.1311168084172.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

SBS JIRA Integration updated AS7-1283:
--------------------------------------

    Forum Reference: http://community.jboss.org/message/616393#616393, http://community.jboss.org/message/612640#612640, http://community.jboss.org/message/615870#615870  (was: http://community.jboss.org/message/615870#615870, http://community.jboss.org/message/612640#612640)


> Cookie-Based Sessions Broken
> ----------------------------
>
>                 Key: AS7-1283
>                 URL: https://issues.jboss.org/browse/AS7-1283
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Final
>            Reporter: Benjamin Browning
>            Assignee: Remy Maucherat
>            Priority: Blocker
>             Fix For: 7.0.1.Final
>
>
> See http://community.jboss.org/message/612763 and http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/003120.html.
> Essentially cookie-based sessions are broken in major browsers and curl unless -Dorg.apache.tomcat.util.http.ServerCookie.FWD_SLASH_IS_SEPARATOR=false is passed on boot. It's likely a large percentage of the people that try AS7 Final will run into this issue and have to spend time trying to figure out why sessions aren't working.
> To summarize the above links, what's happening is the cookie's Path value is being enclosed in quotes. Browsers don't expect this and thus when the browser receives a cookie it doesn't send that cookie back on subsequent requests because the browser doesn't think the cookie's Path value matches the user's path.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 09:23:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 20 Jul 2011 09:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1351) Custom bootstrap
	contexts
Message-ID: <1654580557.69157.1311168203671.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Custom bootstrap contexts
-------------------------

                 Key: AS7-1351
                 URL: https://issues.jboss.org/browse/AS7-1351
             Project: Application Server 7
          Issue Type: Task
          Components: JCA
            Reporter: Jesper Pedersen
            Assignee: Jeff Zhang
            Priority: Critical
             Fix For: 7.1.0.CR1
         Attachments: jboss-jca.xsd

We need to support custom bootstrap contexts, as described in the attached XSD.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 09:23:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 20 Jul 2011 09:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1351) Custom bootstrap
	contexts
In-Reply-To: <1654580557.69157.1311168203671.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <529850801.69164.1311168203841.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated AS7-1351:
---------------------------------

    Attachment: jboss-jca.xsd


> Custom bootstrap contexts
> -------------------------
>
>                 Key: AS7-1351
>                 URL: https://issues.jboss.org/browse/AS7-1351
>             Project: Application Server 7
>          Issue Type: Task
>          Components: JCA
>            Reporter: Jesper Pedersen
>            Assignee: Jeff Zhang
>            Priority: Critical
>             Fix For: 7.1.0.CR1
>
>         Attachments: jboss-jca.xsd
>
>
> We need to support custom bootstrap contexts, as described in the attached XSD.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 09:25:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 20 Jul 2011 09:25:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1352) JCA thread pools must
	be blocking
Message-ID: <29744231.69171.1311168323839.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

JCA thread pools must be blocking
---------------------------------

                 Key: AS7-1352
                 URL: https://issues.jboss.org/browse/AS7-1352
             Project: Application Server 7
          Issue Type: Bug
          Components: JCA
    Affects Versions: 7.0.0.Final
            Reporter: Jesper Pedersen
            Assignee: Jeff Zhang
             Fix For: 7.1.0.Alpha1


The "blocking" attribute for the JCA thread pools should be ignored as it should always be true.

In order to align with other subsystems we will just ignore any value set by the user, and hard code to true.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 09:33:23 2011
From: jira-events at lists.jboss.org (Andy Taylor (JIRA))
Date: Wed, 20 Jul 2011 09:33:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1247) Messaging
 Configuration not support all setings defined in jboss-messaging.xsd schema
 file.
In-Reply-To: <38984762.44637.1310371103789.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1632394356.69219.1311168803925.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615421#comment-12615421 ] 

Andy Taylor commented on AS7-1247:
----------------------------------

Brian, Do you want me to fix this, I've also noticed some missing configuration attributes from the schema to?

Are their any that we don't want to be available in the config, i noticed the following comment in the code

// TODO do we want to allow the jmx configuration ?
        if (params.hasDefined(JMX_DOMAIN)) configuration.setJMXDomain(params.get(JMX_DOMAIN).asString());
        configuration.setJMXManagementEnabled(params.get(JMX_MANAGEMENT_ENABLED).asBoolean(ConfigurationImpl.DEFAULT_JMX_MANAGEMENT_ENABLE





> Messaging Configuration not support all setings defined in jboss-messaging.xsd schema file.
> -------------------------------------------------------------------------------------------
>
>                 Key: AS7-1247
>                 URL: https://issues.jboss.org/browse/AS7-1247
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 7.0.0.CR1
>         Environment: Windows 7 x64
> Java 1.6.25 x64
> JBoss 7.0.0 CR1 - standalone-preview
>            Reporter: Tomaz Zupan
>            Assignee: Brian Stansberry
>              Labels: as7, configuration, jboss, messaging
>         Attachments: standalone-preview.xml
>
>
> Only settings included in standalone-preview.xml configuration file are supported. If some other settings from jboss-messaging.xsd schema file are included,  org.jboss.as.controller.persistence.ConfigurationPersistenceException exception is thrown while the JBoss server is starting.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 09:39:25 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 20 Jul 2011 09:39:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-632) WrapXAResource
 should be true by default
Message-ID: <814831774.69283.1311169165147.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

WrapXAResource should be true by default
----------------------------------------

                 Key: JBJCA-632
                 URL: https://issues.jboss.org/browse/JBJCA-632
             Project: IronJacamar
          Issue Type: Task
          Components: Common
    Affects Versions: 1.0.0.Final
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.1.Final, 1.1.0.Alpha1


Set WrapXAResource to true by default

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 09:41:23 2011
From: jira-events at lists.jboss.org (Alexander Rashed (JIRA))
Date: Wed, 20 Jul 2011 09:41:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1353) Load on startup is
 ignored - JaxWS webservice is always initialized first
Message-ID: <327938746.69301.1311169283795.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Load on startup is ignored - JaxWS webservice is always initialized first
-------------------------------------------------------------------------

                 Key: AS7-1353
                 URL: https://issues.jboss.org/browse/AS7-1353
             Project: Application Server 7
          Issue Type: Feature Request
          Components: Web Services
    Affects Versions: 7.0.0.Final
         Environment: Windows 7
            Reporter: Alexander Rashed
            Assignee: Alessio Soldano


I want to execute a servlet on startup to initialize my environment (for db access, resource management and so on).
This servlet just implements javax.servlet.Servlet.
The other services (using JaxWS) should be instantiated after the Startup-servlet to provide access to the created resources.
But they are always instantiated before the Startup-servlet, even if I use the <load-on-startup> parameter in the web.xml.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 09:43:25 2011
From: jira-events at lists.jboss.org (Jarod Rose (JIRA))
Date: Wed, 20 Jul 2011 09:43:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-9420) JMS Manager is
 unavailable in JBoss Application Server 6.1.0
Message-ID: <254669353.69334.1311169405483.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

JMS Manager is unavailable in JBoss Application Server 6.1.0
------------------------------------------------------------

                 Key: JBAS-9420
                 URL: https://issues.jboss.org/browse/JBAS-9420
             Project: Legacy JBoss Application Server 6 
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMS (HornetQ), Web Console
    Affects Versions: 6.1.0
         Environment: Windows XP SP 3
            Reporter: Jarod Rose
            Assignee: Clebert Suconic


When accessing the Administration Console in JBoss 6.1.0-SNAPSHOT the JMS Manager is unavailable.  When inspecting the log the following stack trace can be found.


2011-07-20 09:21:38,797 INFO  [org.rhq.core.pc.inventory.RuntimeDiscoveryExecutor] (InventoryManager.discovery-1) Scanned [0] servers and found [0] total descendant Resources.
2011-07-20 09:21:38,812 INFO  [org.rhq.core.pc.inventory.RuntimeDiscoveryExecutor] (InventoryManager.discovery-1) Running runtime discovery scan rooted at [platform]
2011-07-20 09:21:38,922 WARN  [org.rhq.core.pc.inventory.InventoryManager] (InventoryManager.discovery-1) Failure during discovery for [JMS Manager] Resources - failed after 0 ms.: java.lang.Exception: Discovery component invocation failed.
	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:283) [:3.0.0]
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_20]
	at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_20]
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_20]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_20]
	at java.lang.Thread.run(Thread.java:619) [:1.6.0_20]
Caused by: java.lang.reflect.UndeclaredThrowableException: Failed to invoke method 'getVersion' on component 'JMSServerMO' with parameters [].
	at org.jboss.profileservice.plugins.management.util.AbstractManagedComponentRuntimeDispatcher.invoke(AbstractManagedComponentRuntimeDispatcher.java:148) [:0.2.2]
	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.invoke(DelegatingComponentDispatcherImpl.java:93) [:0.2.2]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_20]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_20]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121) [jboss-aop.jar:2.2.1.GA]
	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82) [:1.0.1.GA]
	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99) [:6.1.0-SNAPSHOT]
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:967) [:]
	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106) [:]
	at org.jboss.remoting.Client.invoke(Client.java:2070) [:]
	at org.jboss.remoting.Client.invoke(Client.java:879) [:]
	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60) [:1.0.1.GA]
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74) [:1.0.1.GA]
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65) [:1.0.1]
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
	at org.jboss.aop.generatedproxies.AOPProxy$0.invoke(AOPProxy$0.java) [:]
	at org.jboss.profileservice.management.client.ManagedOperationDelegate.invoke(ManagedOperationDelegate.java:63) [:6.1.0-SNAPSHOT]
	at org.jboss.as.integration.hornetq.jopr.JMSManagerDiscoveryComponent.getVersion(JMSManagerDiscoveryComponent.java:74)
	at org.jboss.as.integration.hornetq.jopr.JMSManagerDiscoveryComponent.discoverResources(JMSManagerDiscoveryComponent.java:48)
	at sun.reflect.GeneratedMethodAccessor358.invoke(Unknown Source) [:1.6.0_20]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:279) [:3.0.0]
	... 5 more
Caused by: java.lang.NullPointerException
	at org.jboss.as.integration.hornetq.management.jms.JMSManageMO.getJmsServerControl(JMSManageMO.java:128) [:6.1.0-SNAPSHOT]
	at org.jboss.as.integration.hornetq.management.jms.JMSServerMO.getVersion(JMSServerMO.java:47) [:6.1.0-SNAPSHOT]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_20]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_20]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:60) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300) [jboss-reflect.jar:2.2.1.SP1]
	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:305) [jboss-kernel.jar:2.2.0.SP1]
	at org.jboss.kernel.plugins.registry.basic.LifecycleAwareKernelBus$1.dispatch(LifecycleAwareKernelBus.java:61) [jboss-kernel.jar:2.2.0.SP1]
	at org.jboss.kernel.plugins.registry.basic.LifecycleAwareKernelBus$1.dispatch(LifecycleAwareKernelBus.java:58) [jboss-kernel.jar:2.2.0.SP1]
	at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:71) [jboss-kernel.jar:2.2.0.SP1]
	at org.jboss.kernel.plugins.registry.basic.LifecycleAwareKernelBus.invoke(LifecycleAwareKernelBus.java:57) [jboss-kernel.jar:2.2.0.SP1]
	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.invoke(KernelBusRuntimeComponentDispatcher.java:85) [:0.2.2]
	at org.jboss.profileservice.plugins.management.util.AbstractManagedComponentRuntimeDispatcher.invoke(AbstractManagedComponentRuntimeDispatcher.java:135) [:0.2.2]
	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.invoke(DelegatingComponentDispatcherImpl.java:93) [:0.2.2]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_20]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_20]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121) [jboss-aop.jar:2.2.1.GA]
	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82) [:1.0.1.GA]
	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99) [:6.1.0-SNAPSHOT]
	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:967) [:]
	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106) [:]
	at org.jboss.remoting.Client.invoke(Client.java:2070) [:]
	at org.jboss.remoting.Client.invoke(Client.java:879) [:]
	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60) [:1.0.1.GA]
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74) [:1.0.1.GA]
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65) [:1.0.1]
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
	at org.jboss.aop.generatedproxies.AOPProxy$0.invoke(AOPProxy$0.java) [:]
	at org.jboss.profileservice.management.client.ManagedOperationDelegate.invoke(ManagedOperationDelegate.java:63) [:6.1.0-SNAPSHOT]
	at org.jboss.as.integration.hornetq.jopr.JMSManagerDiscoveryComponent.getVersion(JMSManagerDiscoveryComponent.java:74)
	at org.jboss.as.integration.hornetq.jopr.JMSManagerDiscoveryComponent.discoverResources(JMSManagerDiscoveryComponent.java:48)
	at sun.reflect.GeneratedMethodAccessor358.invoke(Unknown Source) [:1.6.0_20]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:279) [:3.0.0]
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_20]
	at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_20]
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_20]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_20]
	at java.lang.Thread.run(Thread.java:619) [:1.6.0_20]
	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72) [:1.0.1.GA]
	... 18 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 09:45:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 20 Jul 2011 09:45:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-632) WrapXAResource
 should be true by default
In-Reply-To: <814831774.69283.1311169165147.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <894586343.69339.1311169523723.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-632.
-----------------------------------

    Resolution: Done


> WrapXAResource should be true by default
> ----------------------------------------
>
>                 Key: JBJCA-632
>                 URL: https://issues.jboss.org/browse/JBJCA-632
>             Project: IronJacamar
>          Issue Type: Task
>          Components: Common
>    Affects Versions: 1.0.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.1.Final, 1.1.0.Alpha1
>
>
> Set WrapXAResource to true by default

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 09:47:23 2011
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Wed, 20 Jul 2011 09:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1353) Load on startup is
 ignored - JaxWS webservice is always initialized first
In-Reply-To: <327938746.69301.1311169283795.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <153187610.69349.1311169643930.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615425#comment-12615425 ] 

Alessio Soldano commented on AS7-1353:
--------------------------------------

Please open a forum thread on this and link here. Generally speaking, if you have a WS endpoint in your deployment, that's started during the deployment phase. The initialization of the endpoint servlet is just the transport part of that.

> Load on startup is ignored - JaxWS webservice is always initialized first
> -------------------------------------------------------------------------
>
>                 Key: AS7-1353
>                 URL: https://issues.jboss.org/browse/AS7-1353
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>         Environment: Windows 7
>            Reporter: Alexander Rashed
>            Assignee: Alessio Soldano
>              Labels: jaxws, load-on-startup
>
> I want to execute a servlet on startup to initialize my environment (for db access, resource management and so on).
> This servlet just implements javax.servlet.Servlet.
> The other services (using JaxWS) should be instantiated after the Startup-servlet to provide access to the created resources.
> But they are always instantiated before the Startup-servlet, even if I use the <load-on-startup> parameter in the web.xml.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 09:49:25 2011
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Wed, 20 Jul 2011 09:49:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1351) Custom bootstrap
	contexts
In-Reply-To: <1654580557.69157.1311168203671.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <592659206.69368.1311169765173.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

SBS JIRA Integration updated AS7-1351:
--------------------------------------

    Forum Reference: http://community.jboss.org/message/615032#615032


> Custom bootstrap contexts
> -------------------------
>
>                 Key: AS7-1351
>                 URL: https://issues.jboss.org/browse/AS7-1351
>             Project: Application Server 7
>          Issue Type: Task
>          Components: JCA
>            Reporter: Jesper Pedersen
>            Assignee: Jeff Zhang
>            Priority: Critical
>             Fix For: 7.1.0.CR1
>
>         Attachments: jboss-jca.xsd
>
>
> We need to support custom bootstrap contexts, as described in the attached XSD.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 09:55:24 2011
From: jira-events at lists.jboss.org (Alexander Rashed (JIRA))
Date: Wed, 20 Jul 2011 09:55:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1353) Load on startup is
 ignored - JaxWS webservice is always initialized first
In-Reply-To: <327938746.69301.1311169283795.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1604857276.69409.1311170124648.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Rashed updated AS7-1353:
----------------------------------

        Description: 
I want to execute a servlet on startup to initialize my environment (for db access, resource management and so on).
This servlet just implements javax.servlet.Servlet.
The other services (using JaxWS) should be instantiated after the Startup-servlet to provide access to the created resources.
But they are always instantiated before the Startup-servlet, even if I use the <load-on-startup> parameter in the web.xml.

  was:
I want to execute a servlet on startup to initialize my environment (for db access, resource management and so on).
This servlet just implements javax.servlet.Servlet.
The other services (using JaxWS) should be instantiated after the Startup-servlet to provide access to the created resources.
But they are always instantiated before the Startup-servlet, even if I use the <load-on-startup> parameter in the web.xml.


    Forum Reference: http://community.jboss.org/message/616310


Added forum link

> Load on startup is ignored - JaxWS webservice is always initialized first
> -------------------------------------------------------------------------
>
>                 Key: AS7-1353
>                 URL: https://issues.jboss.org/browse/AS7-1353
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>         Environment: Windows 7
>            Reporter: Alexander Rashed
>            Assignee: Alessio Soldano
>              Labels: jaxws, load-on-startup
>
> I want to execute a servlet on startup to initialize my environment (for db access, resource management and so on).
> This servlet just implements javax.servlet.Servlet.
> The other services (using JaxWS) should be instantiated after the Startup-servlet to provide access to the created resources.
> But they are always instantiated before the Startup-servlet, even if I use the <load-on-startup> parameter in the web.xml.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 10:13:24 2011
From: jira-events at lists.jboss.org (Kos Kosta (JIRA))
Date: Wed, 20 Jul 2011 10:13:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1354) Mapping boolean to
 the Oracle DB is not working.
Message-ID: <345583353.69676.1311171204846.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Mapping boolean to the Oracle DB is not working.
------------------------------------------------

                 Key: AS7-1354
                 URL: https://issues.jboss.org/browse/AS7-1354
             Project: Application Server 7
          Issue Type: Bug
          Components: JPA / Hibernate
    Affects Versions: 7.0.0.Final
            Reporter: Kos Kosta
            Assignee: Scott Marlow
            Priority: Blocker
             Fix For: 7.0.1.Final


JBoss 7.0.0.Final, Oracle Database 10g Release 10.2.0.4.0 - 64bit Production, jvm 1.6.24, Linux

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 10:33:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 20 Jul 2011 10:33:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1350) Add management
 operations to assign/unassign handlers from loggers and async handlers.
In-Reply-To: <788349166.68808.1311164783691.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <354865148.69850.1311172403634.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615449#comment-12615449 ] 

David Lloyd commented on AS7-1350:
----------------------------------

The operation names should probably be "add" and "remove" rather than "assign"/"unassign" for consistency with other operations.

> Add management operations to assign/unassign handlers from loggers and async handlers.
> --------------------------------------------------------------------------------------
>
>                 Key: AS7-1350
>                 URL: https://issues.jboss.org/browse/AS7-1350
>             Project: Application Server 7
>          Issue Type: Feature Request
>    Affects Versions: 7.0.0.Final
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>             Fix For: 7.1.0.Alpha1
>
>
> Proposed new management operations:
> For Async Handler:
> assign-subhandler
> unassign-subhandler
> For Root Logger:
> root-logger-assign-handler
> root-logger-unassign-handler
> For other Loggers:
> assign-handler
> unassign-handler

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 11:05:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Wed, 20 Jul 2011 11:05:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1344) JGroups subsystem
 TimerSchedulerAdapter throws UOE when using timer-executor
Message-ID: <260404188.69914.1311174323886.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated AS7-1344:
------------------------------

    Summary: JGroups subsystem TimerSchedulerAdapter throws UOE when using timer-executor  (was: JGroups subsystem TimerScedulerAdapter throws UOE when using timer-executor)


> JGroups subsystem TimerSchedulerAdapter throws UOE when using timer-executor
> ----------------------------------------------------------------------------
>
>                 Key: AS7-1344
>                 URL: https://issues.jboss.org/browse/AS7-1344
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.Final
>            Reporter: Michal Linhard
>            Assignee: Trustin Lee
>
> 07:42:39,535 WARNING [org.jgroups.protocols.UDP] (DiagnosticsHandler,default,perf17-37478) Could not retrieve value of attribute (method) getNumTimerTasks: java.lang.reflect.InvocationTargetException
> [JBoss] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_24]
> [JBoss] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_24]
> [JBoss] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_24]
> [JBoss] 	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_24]
> [JBoss] 	at org.jgroups.stack.Protocol.dumpStats(Protocol.java:272) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at org.jgroups.stack.ProtocolStack.dumpStats(ProtocolStack.java:310) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at org.jgroups.JChannel.dumpStats(JChannel.java:687) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at org.jgroups.JChannel$MyProbeHandler.handleProbe(JChannel.java:2099) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at org.jgroups.protocols.TP$DiagnosticsHandler.handleDiagnosticProbe(TP.java:2165) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at org.jgroups.protocols.TP$DiagnosticsHandler.run(TP.java:2137) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
> [JBoss] Caused by: java.lang.UnsupportedOperationException
> [JBoss] 	at org.jboss.as.clustering.jgroups.TimerSchedulerAdapter.getExecutor(TimerSchedulerAdapter.java:168) [jboss-as-clustering-jgroups-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> [JBoss] 	at org.jboss.as.clustering.jgroups.TimerSchedulerAdapter.size(TimerSchedulerAdapter.java:153) [jboss-as-clustering-jgroups-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> [JBoss] 	at org.jgroups.protocols.TP.getNumTimerTasks(TP.java:714) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	... 11 more
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 11:41:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 20 Jul 2011 11:41:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1355) Review jboss-app.xml
	handling
Message-ID: <798112526.70073.1311176483914.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Review jboss-app.xml handling
-----------------------------

                 Key: AS7-1355
                 URL: https://issues.jboss.org/browse/AS7-1355
             Project: Application Server 7
          Issue Type: Task
          Components: EE
            Reporter: Darran Lofthouse
            Assignee: David Lloyd
             Fix For: 7.1.0.Alpha1


The jboss-app.xml descriptor needs a schema appropriate for AS7 - initially the first missing piece of config is the support for security-domain - the jboss-app.xml descriptor should avoid overlap with jboss-deployment-structure.xml 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 11:41:24 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 20 Jul 2011 11:41:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1355) Review jboss-app.xml
	handling
In-Reply-To: <798112526.70073.1311176483914.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <722232949.70077.1311176484007.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned AS7-1355:
-------------------------------------

    Assignee: Darran Lofthouse  (was: David Lloyd)


> Review jboss-app.xml handling
> -----------------------------
>
>                 Key: AS7-1355
>                 URL: https://issues.jboss.org/browse/AS7-1355
>             Project: Application Server 7
>          Issue Type: Task
>          Components: EE
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 7.1.0.Alpha1
>
>
> The jboss-app.xml descriptor needs a schema appropriate for AS7 - initially the first missing piece of config is the support for security-domain - the jboss-app.xml descriptor should avoid overlap with jboss-deployment-structure.xml 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 11:43:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 20 Jul 2011 11:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1356) JSR-77 support
Message-ID: <305238680.70088.1311176603937.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

JSR-77 support
--------------

                 Key: AS7-1356
                 URL: https://issues.jboss.org/browse/AS7-1356
             Project: Application Server 7
          Issue Type: Task
            Reporter: Brian Stansberry
            Priority: Blocker


Required for EE full profile compliance.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 11:43:24 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 20 Jul 2011 11:43:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1356) JSR-77 support
In-Reply-To: <305238680.70088.1311176603937.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1617603957.70093.1311176604097.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615479#comment-12615479 ] 

Brian Stansberry commented on AS7-1356:
---------------------------------------

I left this unscheduled, but at the latest it has to be done by 7.1.0.CR1.

> JSR-77 support
> --------------
>
>                 Key: AS7-1356
>                 URL: https://issues.jboss.org/browse/AS7-1356
>             Project: Application Server 7
>          Issue Type: Task
>            Reporter: Brian Stansberry
>            Priority: Blocker
>
> Required for EE full profile compliance.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 11:45:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 20 Jul 2011 11:45:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1357) JSR-88 support
In-Reply-To: <623692364.70100.1311176723878.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <261099436.70103.1311176723953.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615480#comment-12615480 ] 

Brian Stansberry commented on AS7-1357:
---------------------------------------

I left this unscheduled, but at the latest it has to be done by 7.1.0.CR1.

> JSR-88 support
> --------------
>
>                 Key: AS7-1357
>                 URL: https://issues.jboss.org/browse/AS7-1357
>             Project: Application Server 7
>          Issue Type: Task
>            Reporter: Brian Stansberry
>            Priority: Blocker
>
> Required for EE full profile certification.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 11:45:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 20 Jul 2011 11:45:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1357) JSR-88 support
Message-ID: <623692364.70100.1311176723878.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

JSR-88 support
--------------

                 Key: AS7-1357
                 URL: https://issues.jboss.org/browse/AS7-1357
             Project: Application Server 7
          Issue Type: Task
            Reporter: Brian Stansberry
            Priority: Blocker


Required for EE full profile certification.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 11:47:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 20 Jul 2011 11:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1182) Incorrect security
 domain selected for web application.
In-Reply-To: <320201656.33784.1309788924180.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1421164786.70120.1311176843947.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615482#comment-12615482 ] 

Darran Lofthouse commented on AS7-1182:
---------------------------------------

Re the jboss.xml handling that is now being addressed in AS7-1211 where a jboss-ejb3.xml descriptor is being introduced.

I have also created AS7-1355 for the jboss-app.xml descriptor as in addition to the security-domain handling there are also additional changes required.

> Incorrect security domain selected for web application.
> -------------------------------------------------------
>
>                 Key: AS7-1182
>                 URL: https://issues.jboss.org/browse/AS7-1182
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: Darran Lofthouse
>         Attachments: test.ear.zip, testcase-src.zip
>
>
> I want to migrate from JBossAS 6 to 7.0.0.CR1. In standalone.xml I declare the following security domain, but get the stacktrace (see below) looking for UsersRolesLoginModule instead of DatabaseServerLoginModule.
> Security domain in standalone.xml:
>    <security-domain name="swe2" cache-type="default">
>       <authentication>
>          <login-module code="Database" flag="required">
>             <module-option name="dsJndiName" value="java:/swe2DS"/>
>             <module-option name="unauthenticatedIdentity" value="gast"/>
>             <module-option name="principalsQuery" value="SELECT password FROM kunde WHERE username=?"/>
>             <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM swe2_role r INNER JOIN kunde k ON r.kunde_fk = k.k_id WHERE k.username=?"/>
>             <module-option name="hashAlgorithm" value="SHA-1"/>
>             <module-option name="hashEncoding" value="base64"/>
>          </login-module>
>       </authentication>
>    </security-domain>
> Stacktrace regarding UsersRolesLoginModule (instead of DatabaseServerLoginModule):
> 16:03:58,528 ERROR [org.jboss.security.auth.spi.UsersRolesLoginModule] (http--127.0.0.1-8080-2) Failed to load users/passwords/role files: java.io.IOException: No properties file: users.properties or defaults: defaultUsers.properties found
> 	at org.jboss.security.auth.spi.Util.loadProperties(Util.java:227) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:188) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:202) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:129) [picketbox-4.0.0.CR1.jar:4.0.0.CR1]
> 	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 javax.security.auth.login.LoginContext.invoke(LoginContext.java:756) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683) [:1.6.0_26]
> 	at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) [:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:579) [:1.6.0_26]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:411) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:154) [picketbox-infinispan-4.0.0.CR1.jar:4.0.0.CR1]
> 	at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:127) [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:180) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:446) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.0.0.CR1.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054) [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 12:11:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 20 Jul 2011 12:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-633) Support <drivers>
	deployments
Message-ID: <1182453899.70159.1311178283689.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Support <drivers> deployments
-----------------------------

                 Key: JBJCA-633
                 URL: https://issues.jboss.org/browse/JBJCA-633
             Project: IronJacamar
          Issue Type: Task
          Components: Deployer, Standalone
    Affects Versions: 1.0.0.Final
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.1.Final, 1.1.0.Alpha1


Add support for <drivers> based deployments in standalone/embedded mode.

Also clarify how driver/module are used in the supported environments.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 12:13:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 20 Jul 2011 12:13:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-633) Support <drivers>
	deployments
In-Reply-To: <1182453899.70159.1311178283689.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <566638330.70162.1311178403636.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-633.
-----------------------------------

    Resolution: Done


> Support <drivers> deployments
> -----------------------------
>
>                 Key: JBJCA-633
>                 URL: https://issues.jboss.org/browse/JBJCA-633
>             Project: IronJacamar
>          Issue Type: Task
>          Components: Deployer, Standalone
>    Affects Versions: 1.0.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.1.Final, 1.1.0.Alpha1
>
>
> Add support for <drivers> based deployments in standalone/embedded mode.
> Also clarify how driver/module are used in the supported environments.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 12:23:23 2011
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Wed, 20 Jul 2011 12:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1350) Add management
 operations to assign/unassign handlers from loggers and async handlers.
In-Reply-To: <788349166.68808.1311164783691.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <230182130.70186.1311179003807.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615486#comment-12615486 ] 

Stan Silvert commented on AS7-1350:
-----------------------------------

The reason I used assign/unassign was because add/remove are create/destroy operations.  So I wanted to distinguish from those.  But if you'd still prefer add/remove I don't have a problem with it.  Just let me know what you prefer.

> Add management operations to assign/unassign handlers from loggers and async handlers.
> --------------------------------------------------------------------------------------
>
>                 Key: AS7-1350
>                 URL: https://issues.jboss.org/browse/AS7-1350
>             Project: Application Server 7
>          Issue Type: Feature Request
>    Affects Versions: 7.0.0.Final
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>             Fix For: 7.1.0.Alpha1
>
>
> Proposed new management operations:
> For Async Handler:
> assign-subhandler
> unassign-subhandler
> For Root Logger:
> root-logger-assign-handler
> root-logger-unassign-handler
> For other Loggers:
> assign-handler
> unassign-handler

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 12:45:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 20 Jul 2011 12:45:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1354) Mapping boolean to
 the Oracle DB is not working.
In-Reply-To: <345583353.69676.1311171204846.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <311072694.70232.1311180323776.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615491#comment-12615491 ] 

Scott Marlow commented on AS7-1354:
-----------------------------------

>From the forum entry, the Hibernate jira issue is https://hibernate.onjira.com/browse/HHH-6463.

> Mapping boolean to the Oracle DB is not working.
> ------------------------------------------------
>
>                 Key: AS7-1354
>                 URL: https://issues.jboss.org/browse/AS7-1354
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Final
>            Reporter: Kos Kosta
>            Assignee: Scott Marlow
>            Priority: Blocker
>              Labels: hibernate, jboss, jpa, worked
>             Fix For: 7.0.1.Final
>
>
> JBoss 7.0.0.Final, Oracle Database 10g Release 10.2.0.4.0 - 64bit Production, jvm 1.6.24, Linux

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 13:17:23 2011
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 20 Jul 2011 13:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-3066) Null comparison
 broken when accessing map content
In-Reply-To: <1249900576.8477.1307445479559.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <946796495.70346.1311182243856.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBRULES-3066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli resolved JBRULES-3066.
------------------------------------

         Assignee: Edson Tirelli  (was: Mark Proctor)
    Fix Version/s: 5.2.1.Final
                   5.3.0.Beta1
       Resolution: Done


MVELClassFieldReader was not properly implementing the equals/hashCode methods, making node sharing wrong. Fixed.

> Null comparison broken when accessing map content
> -------------------------------------------------
>
>                 Key: JBRULES-3066
>                 URL: https://issues.jboss.org/browse/JBRULES-3066
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.2.0.CR1
>            Reporter: Tom?? Schlosser
>            Assignee: Edson Tirelli
>             Fix For: 5.2.1.Final, 5.3.0.Beta1
>
>         Attachments: neq.drl, NeqTest.java, Person.java
>
>
> Comparing item from map to null (to see if given key has a value) gives wrong results.
> The example included results in:
> has mother
> has father
> has mother (using not)
> has father (using not)
> Whereas the right result should be (as is in 5.1):
> doesn't have mother
> has father
> doesn't have mother (using not)
> has father (using not)
> Since the value for for key "mother" is not defined.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Wed Jul 20 13:17:23 2011
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 20 Jul 2011 13:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-3066) Null comparison
 broken when accessing map content
In-Reply-To: <1249900576.8477.1307445479559.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1801688277.70350.1311182243995.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBRULES-3066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-3066.
----------------------------------



> Null comparison broken when accessing map content
> -------------------------------------------------
>
>                 Key: JBRULES-3066
>                 URL: https://issues.jboss.org/browse/JBRULES-3066
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.2.0.CR1
>            Reporter: Tom?? Schlosser
>            Assignee: Edson Tirelli
>             Fix For: 5.2.1.Final, 5.3.0.Beta1
>
>         Attachments: neq.drl, NeqTest.java, Person.java
>
>
> Comparing item from map to null (to see if given key has a value) gives wrong results.
> The example included results in:
> has mother
> has father
> has mother (using not)
> has father (using not)
> Whereas the right result should be (as is in 5.1):
> doesn't have mother
> has father
> doesn't have mother (using not)
> has father (using not)
> Since the value for for key "mother" is not defined.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Wed Jul 20 13:48:23 2011
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Wed, 20 Jul 2011 13:48:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3147) Regression: all
 uppercase field reference results in compile error
Message-ID: <2362491.70386.1311184103681.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Regression: all uppercase field reference results in compile error
------------------------------------------------------------------

                 Key: JBRULES-3147
                 URL: https://issues.jboss.org/browse/JBRULES-3147
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-compiler (expert)
    Affects Versions: 5.2.0.Final
            Reporter: Wolfgang Laun
            Assignee: Mark Proctor
             Fix For: 5.2.1.Final


Consider the following ways of writing getters, setters and pattern field names 

  element  xetter    field  5.1.1   5.3.0
=============================================
  state    xetstate  state    OK     OK
  state    xetState  state    OK     OK
  staTe    xetStaTe  staTe    OK     OK
  state    xetSTATE  STATE    OK     ERR

The last variation is a regression from 5.1.1. It is not so absurd - if the field is designated with an acronym (XML,...) this would be the natural way to write xetters and the pattern field.



--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 15:01:23 2011
From: jira-events at lists.jboss.org (JEE 4 Hire (JIRA))
Date: Wed, 20 Jul 2011 15:01:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBLOGGING-69) null log handle
	in Quartz job
Message-ID: <248485382.70459.1311188483789.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

null log handle in Quartz job
-----------------------------

                 Key: JBLOGGING-69
                 URL: https://issues.jboss.org/browse/JBLOGGING-69
             Project: JBoss Logging
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 3.0.0.GA
            Reporter: JEE 4 Hire
            Assignee: David Lloyd


The instance of org.jboss.logging.Logger does not work inside HelloJob quartz job.
The log handle is null when using:

  @Inject
  private Logger log;

For more info: 
http://seamframework.org/Community/NullEntityManagerInQuartzJob


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 15:05:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Wed, 20 Jul 2011 15:05:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1313) <distributable> web
 applications fail to deploy with the default configuration
In-Reply-To: <540578067.59906.1310987543621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1908232263.70466.1311188723747.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615509#comment-12615509 ] 

Paul Ferraro commented on AS7-1313:
-----------------------------------

Perhaps the clustering dependencies should be optional, so they don't cause deployment to fail.

> <distributable> web applications fail to deploy with the default configuration
> ------------------------------------------------------------------------------
>
>                 Key: AS7-1313
>                 URL: https://issues.jboss.org/browse/AS7-1313
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>            Reporter: Stuart Douglas
>            Assignee: Remy Maucherat
>
> <distributable> web applications fail with the following:
> "Services with missing/unavailable dependencies" => ["jboss.web.\"magnolia-bundled-webapp-4.4.4.war\" missing [ jboss.infinispan.web.___defaultcache ]"]}}}
> At the very least the user should get a better error message explaining why their deployment failed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 15:37:23 2011
From: jira-events at lists.jboss.org (Simon Gunzenreiner (JIRA))
Date: Wed, 20 Jul 2011 15:37:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1313) <distributable> web
 applications fail to deploy with the default configuration
In-Reply-To: <540578067.59906.1310987543621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1948232641.70504.1311190643667.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615515#comment-12615515 ] 

Simon Gunzenreiner commented on AS7-1313:
-----------------------------------------

>From a users point of view, it would be indeed desirable if an application would not need to be re-configured in the deployment descriptor if moved from a development configuration of the AS with no clustering to a production AS with clustering services enabled.

> <distributable> web applications fail to deploy with the default configuration
> ------------------------------------------------------------------------------
>
>                 Key: AS7-1313
>                 URL: https://issues.jboss.org/browse/AS7-1313
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>            Reporter: Stuart Douglas
>            Assignee: Remy Maucherat
>
> <distributable> web applications fail with the following:
> "Services with missing/unavailable dependencies" => ["jboss.web.\"magnolia-bundled-webapp-4.4.4.war\" missing [ jboss.infinispan.web.___defaultcache ]"]}}}
> At the very least the user should get a better error message explaining why their deployment failed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 16:05:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 20 Jul 2011 16:05:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1247) Messaging
 Configuration not support all setings defined in jboss-messaging.xsd schema
 file.
In-Reply-To: <38984762.44637.1310371103789.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <23094539.70531.1311192323695.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615519#comment-12615519 ] 

Brian Stansberry commented on AS7-1247:
---------------------------------------

Andy,

I assigned this to myself not so much because I can fix it all, but because working on it a bit seemed a good way to make also some progress on some general infrastructure to make it easier to deal with the attributes a subsystem exposes. The one commit in this branch illustrates a bit of what I mean:

https://github.com/bstansberry/jboss-as/tree/AS7-1247

There a bit of cruft in there that should come out; the key bit is the AttributeDefinition class in the controller module. It encapsulates key metadata about an attribute and then has some methods the subsystem's parsers, marshallers, operation handlers and descrption providers can use to handle the normal things that are done with an attribute.

As a side benefit, that commit also adds parsing and marshalling support for a bunch of schema elements; basically all the direct children of the subsystem element that are of simple types.

Emanuel Muckenhuber's looking at that commit a bit; you're thoughts would be appreciated as well. If ok, I'll push that into upstream tomorrow. At that point I can assign this to you. I'll be traveling for a few weeks, so I don't want to leave it assigned to myself.

There's other stuff to talk about; probably better to just chat. I'll look for you on IRC tomorrow.  

> Messaging Configuration not support all setings defined in jboss-messaging.xsd schema file.
> -------------------------------------------------------------------------------------------
>
>                 Key: AS7-1247
>                 URL: https://issues.jboss.org/browse/AS7-1247
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 7.0.0.CR1
>         Environment: Windows 7 x64
> Java 1.6.25 x64
> JBoss 7.0.0 CR1 - standalone-preview
>            Reporter: Tomaz Zupan
>            Assignee: Brian Stansberry
>              Labels: as7, configuration, jboss, messaging
>         Attachments: standalone-preview.xml
>
>
> Only settings included in standalone-preview.xml configuration file are supported. If some other settings from jboss-messaging.xsd schema file are included,  org.jboss.as.controller.persistence.ConfigurationPersistenceException exception is thrown while the JBoss server is starting.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 16:19:23 2011
From: jira-events at lists.jboss.org (Kos Kosta (JIRA))
Date: Wed, 20 Jul 2011 16:19:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1354) Mapping boolean to
 the Oracle DB is not working.
In-Reply-To: <345583353.69676.1311171204846.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <94472393.70561.1311193163736.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615522#comment-12615522 ] 

Kos Kosta commented on AS7-1354:
--------------------------------

This issue might not be a blocker for validation, even though the deployment fails if validation is active (which i consider a good thing).

I think what is worse is that fact, that when you try to develop your application in domain-driven manner, you won't be able to deploy against an Oracle DB with a domain that contains a boolean field.

This gives a bad impression about the state of the product.

Is there any possible workaround ? 

> Mapping boolean to the Oracle DB is not working.
> ------------------------------------------------
>
>                 Key: AS7-1354
>                 URL: https://issues.jboss.org/browse/AS7-1354
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Final
>            Reporter: Kos Kosta
>            Assignee: Scott Marlow
>            Priority: Blocker
>              Labels: hibernate, jboss, jpa, worked
>             Fix For: 7.0.1.Final
>
>
> JBoss 7.0.0.Final, Oracle Database 10g Release 10.2.0.4.0 - 64bit Production, jvm 1.6.24, Linux

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 16:21:23 2011
From: jira-events at lists.jboss.org (Kos Kosta (JIRA))
Date: Wed, 20 Jul 2011 16:21:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-1354) Mapping
 boolean to the Oracle DB is not working.
In-Reply-To: <345583353.69676.1311171204846.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <527864603.70564.1311193283660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615522#comment-12615522 ] 

Kos Kosta edited comment on AS7-1354 at 7/20/11 4:19 PM:
---------------------------------------------------------

This issue might not be a blocker for validation, even though the deployment fails if validation is active (which i consider a good thing).

I think what is worse is the fact, that when you try to develop your application in domain-driven manner, you won't be able to deploy against an Oracle DB with a domain that contains a boolean field.

This gives a bad impression about the state of the product.

Is there any possible workaround ? 

      was (Author: softdev):
    This issue might not be a blocker for validation, even though the deployment fails if validation is active (which i consider a good thing).

I think what is worse is that fact, that when you try to develop your application in domain-driven manner, you won't be able to deploy against an Oracle DB with a domain that contains a boolean field.

This gives a bad impression about the state of the product.

Is there any possible workaround ? 
  
> Mapping boolean to the Oracle DB is not working.
> ------------------------------------------------
>
>                 Key: AS7-1354
>                 URL: https://issues.jboss.org/browse/AS7-1354
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Final
>            Reporter: Kos Kosta
>            Assignee: Scott Marlow
>            Priority: Blocker
>              Labels: hibernate, jboss, jpa, worked
>             Fix For: 7.0.1.Final
>
>
> JBoss 7.0.0.Final, Oracle Database 10g Release 10.2.0.4.0 - 64bit Production, jvm 1.6.24, Linux

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 17:30:23 2011
From: jira-events at lists.jboss.org (Chris Lowe (JIRA))
Date: Wed, 20 Jul 2011 17:30:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1358) UserTransaction not
 available to non-EE threads
Message-ID: <15939283.70650.1311197423915.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

UserTransaction not available to non-EE threads
-----------------------------------------------

                 Key: AS7-1358
                 URL: https://issues.jboss.org/browse/AS7-1358
             Project: Application Server 7
          Issue Type: Feature Request
          Components: Transactions
    Affects Versions: 7.0.0.Final
            Reporter: Chris Lowe
            Assignee: Jonathan Halliday


JBoss Seam offers Asynchronous behaviour for non-EJB environments using a Quartz dispatcher. Asynchronous behaviour may also make use of Seam's @Transactional marker to demarcate tx boundaries.

Since testing one of our applications in AS7 I noticed Seam "could not discover transaction status" error messages reported as our application ran async sections of code.

Examining the Seam code, I could see that Seam would make two attempts to access a JNDI UserTransaction resource:

1 - context.lookup("java:comp/UserTransaction");

If an NameNotFoundException is thrown, then attempt:

2 - context.lookup("UserTransaction");

Under AS6 and below, the latter attempt would succeed.  Under AS7 attempts are currently failing.

While looking into this issue I came across the following developer discussion which suggests that it might be possible to add a "java:/jboss/UserTransaction" resource:

http://lists.jboss.org/pipermail/jboss-as7-dev/2011-June/002298.html


Further discussion on my AS7 user forum thread lead to the suggestion that I myself might add this behaviour.

I have followed the implementation hints and light testing has been successful (with appropriate mods to Seam to use the new resource name).  I aim to perform some more thorough testing on this shortly and submit a patch against this issue.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 17:34:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 20 Jul 2011 17:34:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBLOGGING-69) null log handle
	in Quartz job
In-Reply-To: <248485382.70459.1311188483789.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1815713309.70665.1311197663702.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBLOGGING-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved JBLOGGING-69.
----------------------------------

    Resolution: Rejected


This issue has nothing to do with Logging as a project as it does not provide any such injection capability.

> null log handle in Quartz job
> -----------------------------
>
>                 Key: JBLOGGING-69
>                 URL: https://issues.jboss.org/browse/JBLOGGING-69
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.0.0.GA
>            Reporter: JEE 4 Hire
>            Assignee: David Lloyd
>              Labels: quartz
>
> The instance of org.jboss.logging.Logger does not work inside HelloJob quartz job.
> The log handle is null when using:
>   @Inject
>   private Logger log;
> For more info: 
> http://seamframework.org/Community/NullEntityManagerInQuartzJob

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 21:01:23 2011
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Wed, 20 Jul 2011 21:01:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3148) Dynamic
 Declarative Conflict Resolution
Message-ID: <1813939415.70897.1311210083615.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Dynamic Declarative Conflict Resolution
---------------------------------------

                 Key: JBRULES-3148
                 URL: https://issues.jboss.org/browse/JBRULES-3148
             Project: Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Mark Proctor
            Assignee: Mark Proctor


We should be able to use rules to declaratively control conflict resolution.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 21:34:23 2011
From: jira-events at lists.jboss.org (Abhijit Sarkar (JIRA))
Date: Wed, 20 Jul 2011 21:34:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1324) RESTful service
 Servlet configuration fails with ClassCastException
In-Reply-To: <938495355.61579.1311040223621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1423837953.70907.1311212063935.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615552#comment-12615552 ] 

Abhijit Sarkar commented on AS7-1324:
-------------------------------------

This problem is now resolved. Please see the forum reference.

> RESTful service Servlet configuration fails with ClassCastException
> -------------------------------------------------------------------
>
>                 Key: AS7-1324
>                 URL: https://issues.jboss.org/browse/AS7-1324
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>         Environment: Ubuntu 11.04 64 bit, Sun Java 1.6.0_26, JBoss AS 7.0.0.Final 
>            Reporter: Abhijit Sarkar
>            Assignee: Bill Burke
>
> RESTful service fails to deploy with following exception when configured as a Servlet in web.xml. If not configured in web.xml, the service is unavailable on the deployed context path.
> 00:29:32,684 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/movieservicerestful].[MovieServiceRestful]] (http--127.0.0.1-9090-2) Allocate exception for servlet MovieServiceRestful: java.lang.ClassCastException: MovieServiceRestful cannot be cast to javax.servlet.Servlet
> <servlet>
>   <servlet-name>MovieServiceRestful</servlet-name>
>   <servlet-class>MovieServiceRestful</servlet-class>
> </servlet>
> <servlet-mapping>
>   <servlet-name>MovieServiceRestful</servlet-name>
>   <url-pattern>/*</url-pattern>
> </servlet-mapping>

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 21:34:24 2011
From: jira-events at lists.jboss.org (Abhijit Sarkar (JIRA))
Date: Wed, 20 Jul 2011 21:34:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1323) @Resource injection
 on WebServiceContext fails
In-Reply-To: <48156148.61562.1311039863763.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1585183006.70913.1311212064491.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615553#comment-12615553 ] 

Abhijit Sarkar commented on AS7-1323:
-------------------------------------

This problem is now resolved. Please see the forum reference.

> @Resource injection on WebServiceContext fails
> ----------------------------------------------
>
>                 Key: AS7-1323
>                 URL: https://issues.jboss.org/browse/AS7-1323
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>         Environment: Ubuntu 11.04 64 bit, Sun Java 1.6.0_26, JBoss AS 7.0.0.Final
>            Reporter: Abhijit Sarkar
>            Assignee: Alessio Soldano
>
> 00:20:55,004 WARN  [org.jboss.as.ee.component.ResourceInjectionAnnotationParsingProcessor] (MSC service thread 1-4) Can't handle @Resource for ENC name: MovieServiceRestful/wsCtx on class MovieServiceRestful since it's missing a "lookup" (or "mappedName") value and isn't of any known type.
> @WebServiceProvider
> @BindingType(value = HTTPBinding.HTTP_BINDING)
> public class MovieServiceRestful implements Provider<Source> {
>     @Resource
>     protected WebServiceContext wsCtx;
>     ...
> }

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 22:10:23 2011
From: jira-events at lists.jboss.org (winton xu (JIRA))
Date: Wed, 20 Jul 2011 22:10:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-3102)
 InvalidClassException while deserialize knowledgeBase
In-Reply-To: <474632842.21281.1309153763641.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1734942016.70943.1311214223685.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBRULES-3102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

winton xu closed JBRULES-3102.
------------------------------

    Resolution: Won't Fix


I have got a solution to resolve it.
if there is a InvalidClassException, we will create a empty knowledgeBase.
then we will re-build packages/process lazily.

> InvalidClassException while deserialize knowledgeBase
> -----------------------------------------------------
>
>                 Key: JBRULES-3102
>                 URL: https://issues.jboss.org/browse/JBRULES-3102
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>            Reporter: winton xu
>            Assignee: Mark Proctor
>            Priority: Critical
>
> org.drools.rule.MVELDialectRuntimeData have not serialVersionUID defined
> Error:
> {noformat}
> java.io.InvalidClassException: org.drools.rule.MVELDialectRuntimeData; local class incompatible: stream classdesc serialVersionUID = 2609855281272796208, local class serialVersionUID = 5166066541265170937
> 	at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:562) ~[na:1.6.0_20]
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1583) ~[na:1.6.0_20]
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496) ~[na:1.6.0_20]
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732) ~[na:1.6.0_20]
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) ~[na:1.6.0_20]
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) ~[na:1.6.0_20]
> 	at java.util.HashMap.readObject(HashMap.java:1030) ~[na:1.6.0_20]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.6.0_20]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) ~[na:1.6.0_20]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) ~[na:1.6.0_20]
> 	at java.lang.reflect.Method.invoke(Method.java:597) ~[na:1.6.0_20]
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974) ~[na:1.6.0_20]
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849) ~[na:1.6.0_20]
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) ~[na:1.6.0_20]
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) ~[na:1.6.0_20]
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) ~[na:1.6.0_20]
> 	at org.drools.rule.DialectRuntimeRegistry.readExternal(DialectRuntimeRegistry.java:59) ~[org.drools.core_5.3.0.SNAPSHOT.jar:5.3.0-SNAPSHOT]
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792) ~[na:1.6.0_20]
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751) ~[na:1.6.0_20]
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) ~[na:1.6.0_20]
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) ~[na:1.6.0_20]
> 	at org.drools.rule.Package.readExternal(Package.java:191) ~[org.drools.core_5.3.0.SNAPSHOT.jar:5.3.0-SNAPSHOT]
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792) ~[na:1.6.0_20]
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751) ~[na:1.6.0_20]
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) ~[na:1.6.0_20]
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) ~[na:1.6.0_20]
> 	at java.util.HashMap.readObject(HashMap.java:1030) ~[na:1.6.0_20]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.6.0_20]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) ~[na:1.6.0_20]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) ~[na:1.6.0_20]
> 	at java.lang.reflect.Method.invoke(Method.java:597) ~[na:1.6.0_20]
> 	at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:974) ~[na:1.6.0_20]
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1849) ~[na:1.6.0_20]
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) ~[na:1.6.0_20]
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) ~[na:1.6.0_20]
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) ~[na:1.6.0_20]
> 	at org.drools.common.AbstractRuleBase.readExternal(AbstractRuleBase.java:270) ~[org.drools.core_5.3.0.SNAPSHOT.jar:5.3.0-SNAPSHOT]
> 	at org.drools.reteoo.ReteooRuleBase.readExternal(ReteooRuleBase.java:217) ~[org.drools.core_5.3.0.SNAPSHOT.jar:5.3.0-SNAPSHOT]
> 	at org.drools.impl.KnowledgeBaseImpl.readExternal(KnowledgeBaseImpl.java:115) ~[org.drools.core_5.3.0.SNAPSHOT.jar:5.3.0-SNAPSHOT]
> 	at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792) ~[na:1.6.0_20]
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751) ~[na:1.6.0_20]
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) ~[na:1.6.0_20]
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) ~[na:1.6.0_20]
> {noformat}
> Detail: 
> we serialize the KnowledgeBase by the following code.
> {noformat}
>         ByteArrayOutputStream byteStream = new ByteArrayOutputStream();
>         ObjectOutputStream out = new ObjectOutputStream(byteStream);
>         out.writeObject(_kbase);
>         out.close();
>         setKnowledgeBaseContents(byteStream.toByteArray());
> {noformat}
> we deserialize the knowledgebase by the following code.
> {noformat}
>           ByteArrayInputStream bi = new ByteArrayInputStream(info.getData());
>           ObjectInputStream oi = new ObjectInputStream(bi);
>           kbase = (KnowledgeBase) oi.readObject();
>           bi.close();
>           oi.close();
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 22:58:28 2011
From: jira-events at lists.jboss.org (Takayoshi Kimura (JIRA))
Date: Wed, 20 Jul 2011 22:58:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-634) Support query
 timeout for check-valid-connection-sql
Message-ID: <2133115945.71016.1311217108832.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Support query timeout for check-valid-connection-sql
----------------------------------------------------

                 Key: JBJCA-634
                 URL: https://issues.jboss.org/browse/JBJCA-634
             Project: IronJacamar
          Issue Type: Feature Request
          Components: JDBC
    Affects Versions: 1.0.0.Final
            Reporter: Takayoshi Kimura
            Assignee: Jesper Pedersen


When network hangs and check-valid-connection-sql is executed, it hangs until socket timeout which is normally 5min or more longer.

We can avoid this long timeout if we have ability to set query timeout for check-valid-connection-sql and the underlying JDBC driver supports query timeout.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 20 23:00:23 2011
From: jira-events at lists.jboss.org (Takayoshi Kimura (JIRA))
Date: Wed, 20 Jul 2011 23:00:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJCA-634) Support query
 timeout for check-valid-connection-sql
In-Reply-To: <2133115945.71016.1311217108832.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <544653939.71021.1311217223768.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Takayoshi Kimura updated JBJCA-634:
-----------------------------------

    Description: 
When network hangs and check-valid-connection-sql is executed, it hangs until socket timeout which is normally 5min or longer.

We can avoid this long timeout if we have ability to set query timeout for check-valid-connection-sql and the underlying JDBC driver supports query timeout.

  was:
When network hangs and check-valid-connection-sql is executed, it hangs until socket timeout which is normally 5min or more longer.

We can avoid this long timeout if we have ability to set query timeout for check-valid-connection-sql and the underlying JDBC driver supports query timeout.



> Support query timeout for check-valid-connection-sql
> ----------------------------------------------------
>
>                 Key: JBJCA-634
>                 URL: https://issues.jboss.org/browse/JBJCA-634
>             Project: IronJacamar
>          Issue Type: Feature Request
>          Components: JDBC
>    Affects Versions: 1.0.0.Final
>            Reporter: Takayoshi Kimura
>            Assignee: Jesper Pedersen
>
> When network hangs and check-valid-connection-sql is executed, it hangs until socket timeout which is normally 5min or longer.
> We can avoid this long timeout if we have ability to set query timeout for check-valid-connection-sql and the underlying JDBC driver supports query timeout.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 00:58:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 21 Jul 2011 00:58:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-1324) RESTful service
 Servlet configuration fails with ClassCastException
In-Reply-To: <938495355.61579.1311040223621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1299693657.71048.1311224303802.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai closed AS7-1324.
-----------------------------

    Resolution: Rejected


> RESTful service Servlet configuration fails with ClassCastException
> -------------------------------------------------------------------
>
>                 Key: AS7-1324
>                 URL: https://issues.jboss.org/browse/AS7-1324
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>         Environment: Ubuntu 11.04 64 bit, Sun Java 1.6.0_26, JBoss AS 7.0.0.Final 
>            Reporter: Abhijit Sarkar
>            Assignee: Bill Burke
>
> RESTful service fails to deploy with following exception when configured as a Servlet in web.xml. If not configured in web.xml, the service is unavailable on the deployed context path.
> 00:29:32,684 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/movieservicerestful].[MovieServiceRestful]] (http--127.0.0.1-9090-2) Allocate exception for servlet MovieServiceRestful: java.lang.ClassCastException: MovieServiceRestful cannot be cast to javax.servlet.Servlet
> <servlet>
>   <servlet-name>MovieServiceRestful</servlet-name>
>   <servlet-class>MovieServiceRestful</servlet-class>
> </servlet>
> <servlet-mapping>
>   <servlet-name>MovieServiceRestful</servlet-name>
>   <url-pattern>/*</url-pattern>
> </servlet-mapping>

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:00:29 2011
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Thu, 21 Jul 2011 01:00:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3149) ObjectTypeNodes
 are not handled correctly during Marshalling
Message-ID: <1900643845.71053.1311224429189.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

ObjectTypeNodes are not handled correctly during Marshalling
------------------------------------------------------------

                 Key: JBRULES-3149
                 URL: https://issues.jboss.org/browse/JBRULES-3149
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.2.0.Final
            Reporter: Mark Proctor
            Assignee: Mark Proctor
             Fix For: 5.3.0.Beta1


The OTN's are not handled correctly in marshalling. This is where the facthandles are added back into the OTN directly, it doesn't obey all interfaces and super classes. This is fixed in 5.3, but it'll need to be manuall backported to 5.2.x.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:30:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 21 Jul 2011 01:30:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1348) Weld breaks
	RichFaces 4
In-Reply-To: <961263785.68524.1311160163613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <189940347.71073.1311226223758.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615562#comment-12615562 ] 

jaikiran pai commented on AS7-1348:
-----------------------------------

See the solution in this thread http://community.jboss.org/thread/169487?tstart=30. Also see Stan's reply in that thread which says that it's a different EL implementation.


> Weld breaks RichFaces 4
> -----------------------
>
>                 Key: AS7-1348
>                 URL: https://issues.jboss.org/browse/AS7-1348
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 7.0.0.Final
>         Environment: Jenkins build 1402
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>         Attachments: testcase-src.zip, testcase.ear.zip
>
>
> I'm migrating an EAR from JBoss 6 to 7. The Web module is based on RichFaces 4 and Weld. However, I'm getting the stacktrace below. I'll attach a testcase.
> Stacktrace:
> javax.el.ELException: Cannot convert testcase.PasswordGroup of type class java.lang.String to class [Ljava.lang.Class;
> 	at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:470)
> 	at org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:46)
> 	at org.jboss.weld.util.el.ForwardingExpressionFactory.coerceToType(ForwardingExpressionFactory.java:37)
> 	at com.sun.faces.facelets.tag.BeanPropertyTagRule$LiteralPropertyMetadata.applyMetadata(BeanPropertyTagRule.java:88)
> 	at com.sun.faces.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:81)
> 	at javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:129)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:102)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.setAttributes(BehaviorsAddingComponentHandlerWrapper.java:115)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.doNewComponentActions(ComponentTagHandlerDelegateImpl.java:402)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:159)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:82)
> 	at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:152)
> 	at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:744)
> 	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:100)
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> 	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:313)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:662)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:32:39 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 21 Jul 2011 01:32:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1348) RichFaces 4
 application fails with ELException
In-Reply-To: <961263785.68524.1311160163613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1928115546.71079.1311226359727.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated AS7-1348:
------------------------------

    Summary: RichFaces 4 application fails with ELException  (was: Weld breaks RichFaces 4)


> RichFaces 4 application fails with ELException
> ----------------------------------------------
>
>                 Key: AS7-1348
>                 URL: https://issues.jboss.org/browse/AS7-1348
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 7.0.0.Final
>         Environment: Jenkins build 1402
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>         Attachments: testcase-src.zip, testcase.ear.zip
>
>
> I'm migrating an EAR from JBoss 6 to 7. The Web module is based on RichFaces 4 and Weld. However, I'm getting the stacktrace below. I'll attach a testcase.
> Stacktrace:
> javax.el.ELException: Cannot convert testcase.PasswordGroup of type class java.lang.String to class [Ljava.lang.Class;
> 	at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:470)
> 	at org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:46)
> 	at org.jboss.weld.util.el.ForwardingExpressionFactory.coerceToType(ForwardingExpressionFactory.java:37)
> 	at com.sun.faces.facelets.tag.BeanPropertyTagRule$LiteralPropertyMetadata.applyMetadata(BeanPropertyTagRule.java:88)
> 	at com.sun.faces.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:81)
> 	at javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:129)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:102)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.setAttributes(BehaviorsAddingComponentHandlerWrapper.java:115)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.doNewComponentActions(ComponentTagHandlerDelegateImpl.java:402)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:159)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:82)
> 	at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:152)
> 	at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:744)
> 	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:100)
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> 	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:313)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:662)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:38:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 21 Jul 2011 01:38:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1348) RichFaces 4
 application fails with ELException
In-Reply-To: <961263785.68524.1311160163613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <47364736.71083.1311226703975.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned AS7-1348:
-----------------------------------

    Assignee:     (was: Stuart Douglas)


> RichFaces 4 application fails with ELException
> ----------------------------------------------
>
>                 Key: AS7-1348
>                 URL: https://issues.jboss.org/browse/AS7-1348
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 7.0.0.Final
>         Environment: Jenkins build 1402
>            Reporter: Juergen Zimmermann
>         Attachments: testcase-src.zip, testcase.ear.zip
>
>
> I'm migrating an EAR from JBoss 6 to 7. The Web module is based on RichFaces 4 and Weld. However, I'm getting the stacktrace below. I'll attach a testcase.
> Stacktrace:
> javax.el.ELException: Cannot convert testcase.PasswordGroup of type class java.lang.String to class [Ljava.lang.Class;
> 	at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:470)
> 	at org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:46)
> 	at org.jboss.weld.util.el.ForwardingExpressionFactory.coerceToType(ForwardingExpressionFactory.java:37)
> 	at com.sun.faces.facelets.tag.BeanPropertyTagRule$LiteralPropertyMetadata.applyMetadata(BeanPropertyTagRule.java:88)
> 	at com.sun.faces.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:81)
> 	at javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:129)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:102)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.setAttributes(BehaviorsAddingComponentHandlerWrapper.java:115)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.doNewComponentActions(ComponentTagHandlerDelegateImpl.java:402)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:159)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:82)
> 	at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:152)
> 	at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:744)
> 	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:100)
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> 	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:313)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:662)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:49:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 21 Jul 2011 01:49:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1345) sub-deployment
 declared as wrong type in jboss-deployment-structure-1_0.xsd
In-Reply-To: <1406761219.68087.1311145224122.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <571980708.71095.1311227363719.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai reassigned AS7-1345:
---------------------------------

    Assignee: jaikiran pai


> sub-deployment declared as wrong type in jboss-deployment-structure-1_0.xsd
> ---------------------------------------------------------------------------
>
>                 Key: AS7-1345
>                 URL: https://issues.jboss.org/browse/AS7-1345
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Final
>            Reporter: Darrin Mison
>            Assignee: jaikiran pai
>
> I suspect that this is a typo in docs/schema/jboss-deployment-structure-1_0.xsd
> On line 82, should the type of sub-deployment element be "subDeploymentType" ?
> <xsd:element name="sub-deployment" type="deploymentType" minOccurs="0" maxOccurs="unbounded" >
> subDeploymentType is declared on line 149 but doesn't seem to be used.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:25 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1866) Adapt JBM
 tests to new failover model
In-Reply-To: <2021272710.7917.1305686701046.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2037729298.71108.1311227845924.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1866:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Adapt JBM tests to new failover model
> -------------------------------------
>
>                 Key: JBMESSAGING-1866
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1866
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Tests and Performance
>    Affects Versions: 1.4.0.SP3.CP12, 1.4.8.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> In jbm test suite some tests will fail if the 'keepOldFailoverModel' is set to false. This is because with new model, the failover for a dead node doesn't happen immediately. This affects all tests which expect a failover to happen after a certain timeout.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:26 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1852) Make the
 connection failover retry paramters configurable
In-Reply-To: <585667969.36907.1300516185733.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <609988358.71111.1311227846329.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1852:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Make the connection failover retry paramters configurable
> ---------------------------------------------------------
>
>                 Key: JBMESSAGING-1852
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1852
>             Project: JBoss Messaging
>          Issue Type: Enhancement
>          Components: JMS Client Manager
>    Affects Versions: 1.4.0.SP3.CP11, 1.4.7.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> Currently if a connection is broken and the client tries to fail over to a new connection, the retry times and intervals are hardcoded. (10 and 2sec resp.)
> Make it configurable can suit some use cases where the server is shutdown and come back later. (with hardcoded retry, the failover may have given up before the server is back).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:26 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1843) Incorporate
	JBREM-1144
In-Reply-To: <1450854245.31962.1295836069660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1332340615.71116.1311227846573.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1843:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Incorporate JBREM-1144
> ----------------------
>
>                 Key: JBMESSAGING-1843
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1843
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Remoting
>    Affects Versions: 1.4.0.SP3.CP11, 1.4.7.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>            Priority: Critical
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:26 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1834) JBoss
 Messaging XA Recovery Configuration Documentation needs update
In-Reply-To: <1592747324.9787.1292618178047.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1516490165.71120.1311227846755.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1834:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> JBoss Messaging XA Recovery Configuration Documentation needs update
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1834
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1834
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Documentation and Training
>    Affects Versions: 1.4.7.GA
>            Reporter: Bruno Machado
>              Labels: Documentation,, jboss, messaging
>             Fix For: 1.4.8.SP3
>
>
> Chapter JBoss Messaging XA Recovery Configuration[1] has the following paragraph:
> >> DefaultJMSProvider ships with JBoss Enterprise Application Platform. It is defined in $JBOSS_HOME/server/$PROFILE/conf/jms-ds.xml (or, in a clustered environment, hajndi-jms-ds.xml)
> It is confused because jms-ds.xml is placed on $JBOSS_HOME/server/$PROFILE/deploy/messaging, and for clustered environment there is no hajndi-jms-ds.xml.
> [1] http://docs.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/5/html/JBoss_Messaging_User_Guide/recovery.htmljms

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:26 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1833) Intermittent
 test failure -- MultipleFailoverTest.testAllKindsOfServerFailures()
In-Reply-To: <650585879.170.1292419578321.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1994108055.71125.1311227846882.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1833:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Intermittent test failure -- MultipleFailoverTest.testAllKindsOfServerFailures()
> --------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1833
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1833
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Tests and Performance
>    Affects Versions: 1.4.0.SP3.CP11, 1.4.7.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> I'm seeing failure in the test, the stack trace:
> 1) testAllKindsOfServerFailures(org.jboss.test.messaging.jms.clustering.MultipleFailoverTest)javax.jms.JMSException: Cannot find a cached connection factory delegate for node -1
> 	at org.jboss.jms.client.container.ClusteringAspect.handleCreateConnectionDelegate(ClusteringAspect.java:217)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:121)
> 	at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeNext(ClientClusteredConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
> 	at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate.createConnectionDelegate(ClientClusteredConnectionFactoryDelegate.java)
> 	at org.jboss.jms.client.FailoverCommandCenter.failureDetected(FailoverCommandCenter.java:129)
> 	at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:124)
> 	at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
> 	at org.jboss.jms.client.delegate.ClientSessionDelegate$send_6145266547759487588.invokeNext(ClientSessionDelegate$send_6145266547759487588.java)
> 	at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:172)
> 	at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
> 	at org.jboss.jms.client.delegate.ClientSessionDelegate$send_6145266547759487588.invokeNext(ClientSessionDelegate$send_6145266547759487588.java)
> 	at org.jboss.jms.client.delegate.ClientSessionDelegate.send(ClientSessionDelegate.java)
> 	at org.jboss.jms.client.container.ProducerAspect.handleSend(ProducerAspect.java:276)
> 	at org.jboss.aop.advice.org.jboss.jms.client.container.ProducerAspect40.invoke(ProducerAspect40.java)
> 	at org.jboss.jms.client.delegate.ClientProducerDelegate$send_3961598017717988886.invokeNext(ClientProducerDelegate$send_3961598017717988886.java)
> 	at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:172)
> 	at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
> 	at org.jboss.jms.client.delegate.ClientProducerDelegate$send_3961598017717988886.invokeNext(ClientProducerDelegate$send_3961598017717988886.java)
> 	at org.jboss.jms.client.delegate.ClientProducerDelegate.send(ClientProducerDelegate.java)
> 	at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:165)
> 	at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:208)
> 	at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:146)
> 	at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:137)
> 	at org.jboss.test.messaging.jms.clustering.MultipleFailoverTest.testAllKindsOfServerFailures(MultipleFailoverTest.java:174)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at org.jboss.test.messaging.tools.junit.SelectiveTestRunner.main(SelectiveTestRunner.java:58)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:27 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1830) Random
 MultipleFailoverTest failures
In-Reply-To: <496312057.5468.1290663779332.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <542541257.71129.1311227847041.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1830:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Random MultipleFailoverTest failures
> ------------------------------------
>
>                 Key: JBMESSAGING-1830
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1830
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Tests and Performance
>    Affects Versions: 1.4.0.SP3.CP11, 1.4.7.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> The MultipleFailoverTest.testAllKindsOfServerFailures sometimes fails for reason not yet known. So far I have found that the some failoveMap updates didn't get received, so the client didn't failover to the right node.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:27 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1826) Removing a
 reference and deleting a message in DB should be wrapped in a single
 transaction in JDBCPersistenceManager
In-Reply-To: <1108601219.33053.1288578414769.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1142044324.71133.1311227847315.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1826:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Removing a reference and deleting a message in DB should be wrapped in a single transaction in JDBCPersistenceManager 
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1826
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1826
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 1.4.0.SP3.CP10, 1.4.7.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> In JDBCPersistenceManager, when a message is delivered and completed, the message is removed from DB. It includes two deletes in the DB - the reference in JBM_MSG_REF and the message in JBM_MSG. The two deletes are currently done in two separate local transactions as in removeReference() method:
> ...
>          new RemoveReferenceRunner().executeWithRetry();
>          deleteMessage(ref.getMessage().getMessageID());
> ...
> If a server crashes between the two operations, it will leave the tables in an inconsistent state, i.e. ref removed but the message still there. This may result in message stuck, as in this case:
> 1. A server is crashing when a client_ack comes in, the clienk_ack will cause the message to be cleared from the server. If the client_ack processing goes as far as that the removing of reference succeeds but failed to delete the message due to the crashing, the message is left in JBM_MSG table but the corresponding entry in JBM_MSG_REF is gone.
> 2. Eventually the jms client will get ack failure exception. It then expects the messages to be re-delivered after server start-up. But that will never happen. When the server starts up it loads references in JBM_MSG_REF for delivery, but this message's ref is gone.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:27 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1820) Remove
 references to "UsingBatchUpdates" from the *-persistence-service.xml files
 and the documentation.
In-Reply-To: <1965803372.24237.1285366528651.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <261600789.71137.1311227847541.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1820:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Remove references to "UsingBatchUpdates" from the *-persistence-service.xml files and the documentation.
> --------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1820
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1820
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Configuration and Management, Documentation and Training
>    Affects Versions: 1.4.0.SP3.CP10, 1.4.7.GA
>            Reporter: Justin Bertram
>            Assignee: Justin Bertram
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> This feature was removed in JBoss Messaging 1.4.0.CR2, but the documentation and configuration files were never updated.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:27 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1802) Sending
 MapMessage with large String value is broken
In-Reply-To: <1630188419.1271902450691.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <697647454.71143.1311227847866.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1802:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Sending MapMessage with large String value is broken
> ----------------------------------------------------
>
>                 Key: JBMESSAGING-1802
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1802
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>    Affects Versions: 1.4.0.SP3.CP10, 1.4.6.GA
>            Reporter: Justin Bertram
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.8.SP3
>
>
> Sending a javax.jms.MapMessage that has a String value >= 65536 characters fails.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:28 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1794) SecurityStore
 not applied correctly
In-Reply-To: <1428662195.1268928098355.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1162674597.71151.1311227848391.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1794:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> SecurityStore not applied correctly
> -----------------------------------
>
>                 Key: JBMESSAGING-1794
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1794
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Security
>    Affects Versions: 1.4.6.GA
>            Reporter: Justin Bertram
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.8.SP3
>
>
> The "SecurityStore" in messaging-jboss-beans.xml doesn't appear to be getting applied correctly.  Steps to reproduce:
> 1) Unzip a fresh copy of JBoss EAP 5
> 2) Change the "suckerPassword" attribute in <JBOSS_HOME>/server/all/deploy/messaging/messaging-jboss-beans.xml
> 3) Activate TRACE logging with this category in <JBOSS_HOME>/server/all/conf/jboss-log4j.xml:
>    <category name="org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore">
>       <priority value="TRACE"/>
>    </category>
> 4) Start the server: <JBOSS_HOME>/bin/run.sh -c all
> 5) This comes up in the log:
> TRACE [org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore] (main) authenticating user JBM.SUCKER
> TRACE [org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore] (main) Authenticating sucker user
> WARN  [org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore] (main) WARNING! POTENTIAL SECURITY RISK. It has been detected that the MessageSucker component which sucks messages from one node to another has not had its password changed from the installation default. Please see the JBoss Messaging user guide for instructions on how to do this.
> ERROR [org.jboss.messaging.util.ExceptionUtil] (main) ConnectionFactoryEndpoint[jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory] createFailoverConnectionDelegate [da-yi5epx6g-1-0jhcpx6g-twc79y-100j3]
> javax.jms.JMSSecurityException: User JBM.SUCKER is NOT authenticated
>    at org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore.authenticate(JBossASSecurityMetadataStore.java:223)
>    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>    at java.lang.reflect.Method.invoke(Method.java:597)
>    at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93)
>    at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27)
>    at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208)
>    at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120)
>    at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262)
>    at javax.management.StandardMBean.invoke(StandardMBean.java:391)
>    at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
>    at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
>    at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
>    at $Proxy99.authenticate(Unknown Source)
>    at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint.createConnectionDelegateInternal(ServerConnectionFactoryEndpoint.java:233)
>    at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint.createConnectionDelegate(ServerConnectionFactoryEndpoint.java:171)
>    at org.jboss.jms.server.endpoint.advised.ConnectionFactoryAdvised.org$jboss$jms$server$endpoint$advised$ConnectionFactoryAdvised$createConnectionDelegate$aop(ConnectionFactoryAdvised.java:108)
>    at org.jboss.jms.server.endpoint.advised.ConnectionFactoryAdvised.createConnectionDelegate(ConnectionFactoryAdvised.java)
>    at org.jboss.jms.wireformat.ConnectionFactoryCreateConnectionDelegateRequest.serverInvoke(ConnectionFactoryCreateConnectionDelegateRequest.java:91)
>    at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:157)
>    at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:897)
>    at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
>    at org.jboss.remoting.Client.invoke(Client.java:1917)
>    at org.jboss.remoting.Client.invoke(Client.java:768)
>    at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.org$jboss$jms$client$delegate$ClientConnectionFactoryDelegate$createConnectionDelegate$aop(ClientConnectionFactoryDelegate.java:178)
>    at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
>    at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:80)
>    at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect_z_handleCreateConnectionDelegate_15295742.invoke(StateCreationAspect_z_handleCreateConnectionDelegate_15295742.java)
>    at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
>    at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
>    at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:205)
>    at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:87)
>    at org.jboss.messaging.core.impl.clusterconnection.ClusterConnectionManager$ConnectionInfo.start(ClusterConnectionManager.java:669)
>    at org.jboss.messaging.core.impl.clusterconnection.ClusterConnectionManager.ensureAllConnectionsCreated(ClusterConnectionManager.java:419)
>    at org.jboss.messaging.core.impl.clusterconnection.ClusterConnectionManager.notify(ClusterConnectionManager.java:241)
>    at org.jboss.messaging.core.impl.DefaultClusterNotifier.sendNotification(DefaultClusterNotifier.java:72)
>    at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.putReplicantLocally(MessagingPostOffice.java:1245)
>    at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.put(MessagingPostOffice.java:1525)
>    at org.jboss.jms.server.connectionfactory.ConnectionFactoryJNDIMapper.registerConnectionFactory(ConnectionFactoryJNDIMapper.java:252)
>    at org.jboss.jms.server.connectionfactory.ConnectionFactory.startService(ConnectionFactory.java:206)
>    at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
>    at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:269)
>    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.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
>    at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
>    at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
>    at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
>    at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
>    at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
>    at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>    at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
>    at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
>    at $Proxy38.start(Unknown Source)
>    at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
>    at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
>    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.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:297)
>    at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633)
>    at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
>    at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
>    at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
>    at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
>    at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>    at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
>    at org.jboss.system.ServiceController.start(ServiceController.java:460)
>    at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163)
>    at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99)
>    at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
>    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:1440)
>    at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
>    at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
>    at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
>    at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>    at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633)
>    at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
>    at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
>    at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
>    at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
>    at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
>    at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
>    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:403)
>    at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
>    at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633)
>    at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
>    at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
>    at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
>    at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
>    at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
>    at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:308)
>    at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:256)
>    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:619)
> It appears that org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint is creating the connection with the password from messaging-jboss-beans.xml, but org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore is authenticating it with the information from messaging-service.xml (which uses the default password since "SuckerPassword" is commented out).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:28 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1790) A single
 lagging JBM topic subscriber can cause all publishes to lag
In-Reply-To: <491925398.1267127608041.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <555787297.71156.1311227848662.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1790:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> A single lagging JBM topic subscriber can cause all publishes to lag
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1790
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1790
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>         Environment: JBoss 5.1.0_GA, JDK 1.6.0_14 and JDK 1.6.0_18, multiple versions of Windows (2008, 2003, Vista)
>            Reporter: Jason Burton
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.8.SP3
>
>         Attachments: stack_traces.zip
>
>
> We have an application that makes heavy use of JMS topics.  The attached stack traces lead me to believe that we have one client that has some sort of network problem and that JBM is trying to write messages to it.  Evidently this client's socket isn't working anymore.  That's no problem (and maybe could be expected), but this causes every other client publish to hang. 
> The attached stack traces are from JBoss and taken 10 seconds apart during an occurence of this.  During this time, we observed that one or more calls to JBossMessageProducer.publish() took 50 seconds to complete (normally takes 2-5 milliseconds).  Best I can tell, the "WorkManager(2)-3" thread is the culprit.  Over the 50 seconds, it seemed to be stuck in a socketWrite() and has object <0x143a2250>  locked.  There are a few other publishing threads waiting on that lock.
> I'm pretty sure this relates to a closed bug:
> https://jira.jboss.org/jira/browse/JBMESSAGING-1220
> This bug report states to run a client out of memory to reproduce the problem, but at the point of the attached server stack traces. there aren't any clients that are out of memory.  We have been able to reproduce this by running a client out of memory, though.  That bug report stated to reduce the prefetchSize to a number of messages whose size would be under the TCP window size.  Best I can tell by searching, the TCP window size defaults to 16K on Windows.  It is definitely possible that the messages we send are larger than 16K, so even setting the prefetchSize to 1 would be larger that the TCP window size.
> Let me know if you need any more information.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:28 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1789) setFetchSize
 used in JDBCPersistenceManager with too large value for oracle (200000)
In-Reply-To: <434408512.1265883611705.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1131273024.71161.1311227848894.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1789:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> setFetchSize used in JDBCPersistenceManager with too large value for oracle (200000)
> ------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1789
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1789
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core Persistence
>    Affects Versions: 1.4.5.GA, 1.4.6.GA, 1.4.8.GA
>         Environment: oracle
>            Reporter: Simo Nikula
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> in method loadFromStart (line 984 in 1.4.6) fetchSize is set based on parameter number which is as default 200000.
> setting max rows using setMaxRows with same value would be correct way to limit result set.
> java.sql.SQLException: Bigger type length than Maximum
>         at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:70)
>         at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:133)
>         at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:199)
>         at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:263)
>         at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:271)
>         at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:445)
>         at oracle.jdbc.driver.T4CMAREngine.buffer2Value(T4CMAREngine.java:2253)
>         at oracle.jdbc.driver.T4CMAREngine.unmarshalUB2(T4CMAREngine.java:1101)
>         at oracle.jdbc.driver.T4C8TTIrxh.unmarshalV10(T4C8TTIrxh.java:115)
>         at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:654)
>         at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:194)
>         at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:791)
>         at oracle.jdbc.driver.T4CPreparedStatement.executeMaybeDescribe(T4CPreparedStatement.java:866)
>         at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1186)
>         at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3387)
>         at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3431)
>         at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeQuery(OraclePreparedStatementWrapper.java:1491)
>         at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:342)
>         at org.jboss.messaging.core.impl.JDBCPersistenceManager.loadFromStart(JDBCPersistenceManager.java:988)
>         at org.jboss.messaging.core.impl.PagingChannelSupport.load(PagingChannelSupport.java:211)
>         at org.jboss.jms.server.destination.TopicService.startService(TopicService.java:92)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
>         at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:269)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:30 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1782) on cluster
 hiccup jbossmessaging dies
In-Reply-To: <57052573.1263200910802.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <706211808.71173.1311227850100.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1782:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> on cluster hiccup jbossmessaging dies
> -------------------------------------
>
>                 Key: JBMESSAGING-1782
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1782
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.3.GA, 1.4.6.GA
>         Environment: jboss 5.1
> jboss groups 2.6.13 GA
>            Reporter: Armin Haaf
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.8.SP3
>
>         Attachments: ejbtest.tgz
>
>
> sometimes we have a problem with our cluster loosing  a socket connection. Groups come up again, but messaging dies and  is no longer usable on this node.
> Node 1 gots suspected by node 2 (i'm not sure why). Node 1 gets removed from the cluster and trys to reconnect. Reconnect seems to work, but messaging is now dead
> output from node1:
> 2010-01-11 04:24:17,070 ERROR [org.jgroups.blocks.ConnectionTable] [T:169] failed sending data to 10.199.12.135:7900: java.net.SocketException: Broken pipe
> 2010-01-11 04:24:17,072 WARN  [org.jgroups.protocols.FD] [T:48734] I was suspected by 10.199.12.135:32792; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
> 2010-01-11 04:24:17,072 WARN  [org.jgroups.protocols.FD] [T:48717] I was suspected by 10.199.12.135:32792; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
> 2010-01-11 04:24:17,073 WARN  [org.jgroups.protocols.FD] [T:48720] I was suspected by 10.199.12.135:32792; ignoring the SUSPECT message and sending back a HEARTBEAT_ACK
> 2010-01-11 04:24:17,073 WARN  [org.jgroups.protocols.pbcast.GMS] [T:67] I (10.199.12.134:32797) am not a member of view [10.199.12.135:32792|12] [10.199.12.135:32792], shunning myself
> and leaving the group (prev_members are [10.199.12.135:32792, 10.199.12.134:32797], current view is [10.199.12.135:32792|11] [10.199.12.135:32792, 10.199.12.134:32797])
> 2010-01-11 04:24:17,073 WARN  [org.jgroups.protocols.pbcast.GMS] [T:48721] I (10.199.12.134:32797) am not a member of view [10.199.12.135:32792|10] [10.199.12.135:32792], shunning myse
> lf and leaving the group (prev_members are [10.199.12.135:32792, 10.199.12.134:32797], current view is [10.199.12.135:32792|9] [10.199.12.135:32792, 10.199.12.134:32797])
> 2010-01-11 04:24:17,074 WARN  [org.jgroups.protocols.pbcast.GMS] [T:48719] I (10.199.12.134:32797) am not a member of view [10.199.12.135:32792|12] [10.199.12.135:32792], shunning myse
> lf and leaving the group (prev_members are [10.199.12.135:32792, 10.199.12.134:32797], current view is [10.199.12.135:32792|11] [10.199.12.135:32792, 10.199.12.134:32797])
> 2010-01-11 04:24:17,075 ERROR [org.jgroups.protocols.UNICAST] [T:48718] 10.199.12.134:32797: sender window for 10.199.12.135:32792 not found
> 2010-01-11 04:24:17,585 INFO  [STDOUT] [T:48741]
> ---------------------------------------------------------
> GMS: address is 10.199.12.134:32799 (cluster=lisa2000)
> ---------------------------------------------------------
> 2010-01-11 04:24:17,591 INFO  [org.jboss.ha.framework.interfaces.HAPartition.lisa2000] [T:48741] New cluster view for partition lisa2000: 11 ([10.199.12.135:1099, 10.199.12.134:1099] d
> elta: 0)
> 2010-01-11 04:24:17,593 INFO  [STDOUT] [T:48742]
> ---------------------------------------------------------
> GMS: address is 10.199.12.134:32799 (cluster=MessagingPostOffice-CTRL)
> ---------------------------------------------------------
> 2010-01-11 04:24:17,594 INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:101] I am (10.199.12.134:1099) received membershipChanged event:
> 2010-01-11 04:24:17,594 INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:101] Dead members: 0 ([])
> 2010-01-11 04:24:17,594 INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:101] New Members : 0 ([])
> 2010-01-11 04:24:17,594 INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:101] All Members : 2 ([10.199.12.135:1099, 10.199.12.134:1099])
> 2010-01-11 04:24:17,601 INFO  [STDOUT] [T:48740]
> ---------------------------------------------------------
> GMS: address is 10.199.12.134:32799 (cluster=lisa2000-HAPartitionCache)
> ---------------------------------------------------------
> 2010-01-11 04:24:17,601 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:48742] org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 429c429c g
> ot new view [10.199.12.135:32792|13] [10.199.12.135:32792, 10.199.12.134:32799], old view is [10.199.12.135:32792|11] [10.199.12.135:32792, 10.199.12.134:32797]
> 2010-01-11 04:24:17,601 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:48742] I am (10.199.12.134:32799)
> 2010-01-11 04:24:17,609 INFO  [org.jboss.cache.RPCManagerImpl] [T:48740] Received new cluster view: [10.199.12.135:32792|13] [10.199.12.135:32792, 10.199.12.134:32799]
> 2010-01-11 04:24:17,617 INFO  [org.jboss.cache.statetransfer.LegacyStateTransferIntegrator] [T:48753] Using version 4096
> 2010-01-11 04:24:19,686 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:48742] Dead members: 1 ([10.199.12.134:32797])
> 2010-01-11 04:24:19,686 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:48742] New Members : 1 ([10.199.12.134:32799])
> 2010-01-11 04:24:19,686 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:48742] All Members : 2 ([10.199.12.135:32792, 10.199.12.134:32799])
> 2010-01-11 04:24:25,437 INFO  [lisa.logistics.core.ejb.CommandExecutionBean] [T:782] Execute of ping takes 10 ms.
> 2010-01-11 04:24:28,705 ERROR [org.jboss.messaging.util.ExceptionUtil] [T:194] ConnectionEndpoint[l26-sy0xoa4g-1-qtygu64g-qp6dlm-q3cj5a] createSessionDelegate [t26-d91xoa4g-1-qtygu64g-
> qp6dlm-q3cj5a]
> java.lang.IllegalStateException: Cannot find binding for queue DLQ
>         at org.jboss.jms.server.ServerPeer.getDefaultDLQInstance(ServerPeer.java:1254)
>         at org.jboss.jms.server.endpoint.ServerSessionEndpoint.<init>(ServerSessionEndpoint.java:228)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:249)
>         at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$createSessionDelegate$aop(ConnectionAdvised.java:75)
>         at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$createSessionDelegate_6052335267724906805.invokeTarget(ConnectionAdvised$createSessionDelegate_6052335267724906805.ja
> va)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
>         at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.createSessionDelegate(ConnectionAdvised.java)
>         at org.jboss.jms.wireformat.ConnectionCreateSessionDelegateRequest.serverInvoke(ConnectionCreateSessionDelegateRequest.java:87)
>         at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:143)
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
>         at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:744)
>         at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:697)
>         at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
>         at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
> output from node 2:
> 2010-01-11 04:24:15,618 INFO  [org.jboss.ha.framework.interfaces.HAPartition.lifecycle.lisa2000] [T:46047] Suspected member: 10.199.12.134:32797
> 2010-01-11 04:24:15,680 INFO  [org.jboss.ha.framework.interfaces.HAPartition.lifecycle.lisa2000] [T:89] New cluster view for partition lisa2000 (id: 10, delta: -1) : [10.199.1
> 2.135:1099]
> 2010-01-11 04:24:15,681 INFO  [org.jboss.cache.RPCManagerImpl] [T:89] Received new cluster view: [10.199.12.135:32792|12] [10.199.12.135:32792]
> 2010-01-11 04:24:15,682 INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:106] I am (10.199.12.135:1099) received membershipChanged event:
> 2010-01-11 04:24:15,682 INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:106] Dead members: 1 ([10.199.12.134:1099])
> 2010-01-11 04:24:15,682 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:108] org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 443
> 24432 got new view [10.199.12.135:32792|12] [10.199.12.135:32792], old view is [10.199.12.135:32792|11] [10.199.12.135:32792, 10.199.12.134:32797]
> 2010-01-11 04:24:15,682 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:108] I am (10.199.12.135:32792)
> 2010-01-11 04:24:15,683 ERROR [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:108] Caught Exception in MembershipListener
> java.lang.IllegalStateException: org.jboss.messaging.core.impl.postoffice.MessagingPostOffice at 2b4e2b4e cannot find node ID for address 10.199.12.134:32797
>         at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.nodesLeft(MessagingPostOffice.java:942)
>         at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener.viewAccepted(GroupMember.java:508)
>         at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUpEvent(MessageDispatcher.java:733)
>         at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:776)
>         at org.jgroups.JChannel.up(JChannel.java:1336)
>         at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:454)
>         at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:435)
>         at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:153)
>         at org.jgroups.protocols.FRAG2.up(FRAG2.java:188)
>         at org.jgroups.protocols.FC.up(FC.java:493)
>         at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:543)
>         at org.jgroups.protocols.pbcast.CoordGmsImpl.handleViewChange(CoordGmsImpl.java:463)
>         at org.jgroups.protocols.pbcast.GMS.up(GMS.java:749)
>         at org.jgroups.protocols.VIEW_SYNC.up(VIEW_SYNC.java:192)
>         at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:233)
>         at org.jgroups.protocols.UNICAST.up(UNICAST.java:328)
>         at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:895)
>         at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:708)
>         at org.jgroups.protocols.BARRIER.up(BARRIER.java:136)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:167)
>         at org.jgroups.protocols.FD.up(FD.java:284)
>         at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:307)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:144)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:262)
>         at org.jgroups.protocols.PING.up(PING.java:273)
>         at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2315)
>         at org.jgroups.protocols.TP.passMessageUp(TP.java:1249)
>         at org.jgroups.protocols.TP.access$100(TP.java:49)
>         at org.jgroups.protocols.TP$1.run(TP.java:1176)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:736)
> 2010-01-11 04:24:15,682 INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:106] New Members : 0 ([])
> 2010-01-11 04:24:15,683 INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:106] All Members : 1 ([10.199.12.135:1099])
> 2010-01-11 04:24:17,033 WARN  [org.jgroups.protocols.pbcast.NAKACK] [T:46042] 10.199.12.135:32792] discarded message from non-member 10.199.12.134:32797, my view is [10.199.12
> .135:32792|12] [10.199.12.135:32792]
> 2010-01-11 04:24:17,033 WARN  [org.jgroups.protocols.pbcast.NAKACK] [T:46041] 10.199.12.135:32792] discarded message from non-member 10.199.12.134:32797, my view is [10.199.12
> .135:32792|10] [10.199.12.135:32792]
> 2010-01-11 04:24:17,069 WARN  [org.jgroups.protocols.pbcast.NAKACK] [T:46041] 10.199.12.135:32792] discarded message from non-member 10.199.12.134:32797, my view is [10.199.12
> .135:32792|10] [10.199.12.135:32792]
> 2010-01-11 04:24:17,072 WARN  [org.jgroups.protocols.pbcast.NAKACK] [T:45905] 10.199.12.135:7900] discarded message from non-member 10.199.12.134:7900, my view is [10.199.12.1
> 35:7900|10] [10.199.12.135:7900]
> 2010-01-11 04:24:17,589 INFO  [org.jboss.ha.framework.interfaces.HAPartition.lifecycle.lisa2000] [T:103] New cluster view for partition lisa2000 (id: 11, delta: 1) : [10.199.1
> 2.135:1099, 10.199.12.134:1099]
> 2010-01-11 04:24:17,589 INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:106] I am (10.199.12.135:1099) received membershipChanged event:
> 2010-01-11 04:24:17,589 INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:106] Dead members: 0 ([])
> 2010-01-11 04:24:17,589 INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:106] New Members : 1 ([10.199.12.134:1099])
> 2010-01-11 04:24:17,589 INFO  [org.jboss.ha.framework.server.DistributedReplicantManagerImpl.lisa2000] [T:106] All Members : 2 ([10.199.12.135:1099, 10.199.12.134:1099])
> 2010-01-11 04:24:17,597 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:113] org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener at 443
> 24432 got new view [10.199.12.135:32792|13] [10.199.12.135:32792, 10.199.12.134:32799], old view is [10.199.12.135:32792|12] [10.199.12.135:32792]
> 2010-01-11 04:24:17,597 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:113] I am (10.199.12.135:32792)
> 2010-01-11 04:24:17,597 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:113] New Members : 1 ([10.199.12.134:32799])
> 2010-01-11 04:24:17,597 INFO  [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:113] All Members : 2 ([10.199.12.135:32792, 10.199.12.134:32799])
> 2010-01-11 04:24:17,607 INFO  [org.jboss.cache.RPCManagerImpl] [T:99] Received new cluster view: [10.199.12.135:32792|13] [10.199.12.135:32792, 10.199.12.134:32799]
> 2010-01-11 04:24:19,609 WARN  [org.jgroups.protocols.pbcast.GMS] [T:46052] 10.199.12.135:32792 failed to collect all ACKs (1) for unicasted view [10.199.12.135:32792|13] [10.1
> 99.12.135:32792, 10.199.12.134:32799] after 2000ms, missing ACKs from [10.199.12.134:32799], local_addr=10.199.12.135:32792
> 2010-01-11 04:24:19,611 ERROR [org.jboss.messaging.core.impl.postoffice.UnbindRequest] [T:875] Failed to remove binding
> java.lang.IllegalStateException: Don't know about node id: 1
>         at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.removeBindingFromCluster(MessagingPostOffice.java:1079)
>         at org.jboss.messaging.core.impl.postoffice.UnbindRequest.execute(UnbindRequest.java:61)
>         at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlRequestHandler.handle(GroupMember.java:622)
>         at org.jgroups.blocks.MessageDispatcher.handle(MessageDispatcher.java:616)
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:637)
>         at org.jgroups.blocks.RequestCorrelator$Request.run(RequestCorrelator.java:944)
>         at org.jgroups.util.ReusableThread.run(ReusableThread.java:220)
>         at java.lang.Thread.run(Thread.java:736)
> 2010-01-11 04:24:19,611 ERROR [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:875] Caught Exception in RequestHandler
> java.lang.Exception: Failed to remove binding
>         at org.jboss.messaging.core.impl.postoffice.UnbindRequest.execute(UnbindRequest.java:67)
>         at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlRequestHandler.handle(GroupMember.java:622)
>         at org.jgroups.blocks.MessageDispatcher.handle(MessageDispatcher.java:616)
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:637)
>         at org.jgroups.blocks.RequestCorrelator$Request.run(RequestCorrelator.java:944)
>         at org.jgroups.util.ReusableThread.run(ReusableThread.java:220)
>         at java.lang.Thread.run(Thread.java:736)
> Caused by:
> java.lang.IllegalStateException: Don't know about node id: 1
>         at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.removeBindingFromCluster(MessagingPostOffice.java:1079)
>         at org.jboss.messaging.core.impl.postoffice.UnbindRequest.execute(UnbindRequest.java:61)
>         ... 6 more
> 2010-01-11 04:24:19,611 ERROR [org.jgroups.blocks.RequestCorrelator] [T:875] error invoking method
> java.lang.IllegalStateException: Failed to remove binding
>         at org.jboss.messaging.core.impl.postoffice.UnbindRequest.execute(UnbindRequest.java:67)
>         at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlRequestHandler.handle(GroupMember.java:622)
>         at org.jgroups.blocks.MessageDispatcher.handle(MessageDispatcher.java:616)
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:637)
>         at org.jgroups.blocks.RequestCorrelator$Request.run(RequestCorrelator.java:944)
>         at org.jgroups.util.ReusableThread.run(ReusableThread.java:220)
>         at java.lang.Thread.run(Thread.java:736)
> 2010-01-11 04:24:19,622 ERROR [org.jboss.messaging.core.impl.postoffice.UnbindRequest] [T:875] Failed to remove binding
> java.lang.IllegalStateException: Don't know about node id: 1
>         at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.removeBindingFromCluster(MessagingPostOffice.java:1079)
>         at org.jboss.messaging.core.impl.postoffice.UnbindRequest.execute(UnbindRequest.java:61)
>         at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlRequestHandler.handle(GroupMember.java:622)
>         at org.jgroups.blocks.MessageDispatcher.handle(MessageDispatcher.java:616)
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:637)
>         at org.jgroups.blocks.RequestCorrelator$Request.run(RequestCorrelator.java:944)
>         at org.jgroups.util.ReusableThread.run(ReusableThread.java:220)
>         at java.lang.Thread.run(Thread.java:736)
> 2010-01-11 04:24:19,623 ERROR [org.jboss.messaging.core.impl.postoffice.GroupMember] [T:875] Caught Exception in RequestHandler
> java.lang.Exception: Failed to remove binding
>         at org.jboss.messaging.core.impl.postoffice.UnbindRequest.execute(UnbindRequest.java:67)
>         at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlRequestHandler.handle(GroupMember.java:622)
>         at org.jgroups.blocks.MessageDispatcher.handle(MessageDispatcher.java:616)
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:637)
>         at org.jgroups.blocks.RequestCorrelator$Request.run(RequestCorrelator.java:944)
>         at org.jgroups.util.ReusableThread.run(ReusableThread.java:220)
>         at java.lang.Thread.run(Thread.java:736)
> Caused by:
> java.lang.IllegalStateException: Don't know about node id: 1
>         at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.removeBindingFromCluster(MessagingPostOffice.java:1079)
>         at org.jboss.messaging.core.impl.postoffice.UnbindRequest.execute(UnbindRequest.java:61)
>         ... 6 more
> 2010-01-11 04:24:19,623 ERROR [org.jgroups.blocks.RequestCorrelator] [T:875] error invoking method
> java.lang.IllegalStateException: Failed to remove binding
>         at org.jboss.messaging.core.impl.postoffice.UnbindRequest.execute(UnbindRequest.java:67)
>         at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlRequestHandler.handle(GroupMember.java:622)
>         at org.jgroups.blocks.MessageDispatcher.handle(MessageDispatcher.java:616)
>         at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:637)
>         at org.jgroups.blocks.RequestCorrelator$Request.run(RequestCorrelator.java:944)
>         at org.jgroups.util.ReusableThread.run(ReusableThread.java:220)
>         at java.lang.Thread.run(Thread.java:736)
> 2010-01-11 04:24:23,881 WARN  [org.jgroups.protocols.pbcast.NAKACK] [T:46065] 10.199.12.135:7900] discarded message from non-member 10.199.12.134:7900, my view is [10.199.12.1
> 35:7900|10] [10.199.12.135:7900]
> 2010-01-11 04:24:32,813 WARN  [org.jgroups.protocols.pbcast.NAKACK] [T:46065] 10.199.12.135:7900] discarded message from non-member 10.199.12.134:7900, my view is [10.199.12.1
> 35:7900|10] [10.199.12.135:7900]
> 2010-01-11 04:24:33,501 WARN  [org.jgroups.protocols.pbcast.NAKACK] [T:46065] 10.199.12.135:7900] discarded message from non-member 10.199.12.134:7900, my view is [10.199.12.1
> 35:7900|10] [10.199.12.135:7900]
> 2010-01-11 04:24:45,201 WARN  [org.jgroups.protocols.pbcast.NAKACK] [T:46069] 10.199.12.135:7900] discarded message from non-member 10.199.12.134:7900, my view is [10.199.12.1
> 35:7900|10] [10.199.12.135:7900]
> 2010-01-11 04:24:53,645 ERROR [org.jgroups.blocks.ConnectionTable] [T:171] failed sending data to 10.199.12.134:7900: java.net.SocketException: Socket closed

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:30 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1781) JMS failover
 recovery handling failed on cluster setup when the server running with
 JBOss + MySQL crashes.
In-Reply-To: <2061076250.1263195450673.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <607285222.71177.1311227850566.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1781:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> JMS failover recovery handling failed on cluster setup when the server running with JBOss + MySQL crashes.
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1781
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1781
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.3.GA
>         Environment: java version "1.6.0_17"
> JBoss version 5.1.0.GA
> Operating System: Solaris & Linux 
>            Reporter: saravanan M
>             Fix For: 1.4.8.SP3
>
>
> JBoss Messaging failover recovery handling failed on cluster setup when the server running with JBOss + MySQL crashes.
> Setup details
> server1: JBoss App server + MySQL 
> server2: JBoss App server
> server1 was crashed for some hardware failure, server2 detects that the server1 leaves the cluster and starts the failover recovery operation, failover 
> recovery involves clean up operation from its local map and database, how ever MySQL is down at this moment so the clean up operation failed with some re-tries.
> Restarting the crashed server does not help to join the existing cluster group, the reason being failover recovery has failed. 
> 009-11-24 21:43:24,101 ERROR [main]-[org.jboss.messaging.util.ExceptionUtil] org.jboss.messaging.core.jmx.MessagingPostOfficeService at 1a67848 startService
> java.lang.IllegalArgumentException: Cannot start post office since there is already a post office in the cluster with the same node id (215). Are you sure 
> you have given each node a unique node id during installation?
> at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.start(MessagingPostOffice.java:372)
> at org.jboss.messaging.core.jmx.MessagingPostOfficeService.startService(MessagingPostOfficeService.java:462)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
> at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:269)
> 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.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
> at $Proxy38.start(Unknown Source)
> at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
> at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
> 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.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:286)
> 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.ServiceController.doChange(ServiceController.java:688)
> at org.jboss.system.ServiceController.start(ServiceController.java:460)
> at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163)
> at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99)
> at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
> 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:619) 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:30 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1780) When i change
 the default db schemas of jbm tables the DLQ - if it contains message - run
 in deadlock by the next server restart,
 because it wants to use the default schema instead of the modified db schema
In-Reply-To: <1742553701.1263157710719.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1166021501.71183.1311227850917.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1780:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> When i change the default db schemas of jbm tables the DLQ - if it contains message -  run in deadlock by the next server restart, because it wants to use the default schema instead of the modified db schema 
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1780
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1780
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP09, 1.4.5.GA, 1.4.6.GA
>         Environment: JBoss 5.1.GA+Seam 2.1.1.GA+mysql 5.1
>            Reporter: bb bb
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> At first, I modified the default schema of jbm tables in mysql-persistence-service.xml
> so, I changed the sql properties  JBM_DUAL to  newSchema.JBM_DUAL and so on...
> Everything works fine with the modified schema, until I add a posion message to the dead letter queue.
> Then I want to restart the JBoss server, I get an exception to it run in dead lock, because didn't find the jbm_msg tables (but it would be newSchema.jbm_msg  )

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:31 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1777) Error in
 addMessageIDInHeader while bridging from JBossMQ
In-Reply-To: <2100273285.1261511190714.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <995396083.71188.1311227851167.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1777:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Error in addMessageIDInHeader while bridging from JBossMQ
> ---------------------------------------------------------
>
>                 Key: JBMESSAGING-1777
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1777
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.3.GA
>         Environment: JBoss AS 5.1.0.GA
>            Reporter: Pedro Gontijo
>            Assignee: Yong Hao Gao
>              Labels: JMSXDeliveryCount, addMessageIDInHeader, bridge, jbossmq
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> When addMessageIDInHeader is set to true in a JBossMQ->JBM bridge scenerio the following error occurs:
> WARN  [org.jboss.jms.server.bridge.Bridge] (Thread-27) jboss.messaging:name=MyBridge,service=Bridge Failed to send + acknowledge batch, closing JMS objects
> javax.jms.JMSException: Illegal property name: JMSXDeliveryCount
> 	at org.jboss.mq.SpyMessage.checkProperty(Unknown Source)
> 	at org.jboss.mq.SpyMessage.setObjectProperty(Unknown Source)
> 	at org.jboss.jms.server.bridge.Bridge.addMessageIDInHeader(Bridge.java:1481)
> 	at org.jboss.jms.server.bridge.Bridge.sendMessages(Bridge.java:1391)
> 	at org.jboss.jms.server.bridge.Bridge.sendBatchNonTransacted(Bridge.java:1261)
> 	at org.jboss.jms.server.bridge.Bridge.sendBatch(Bridge.java:1375)
> 	at org.jboss.jms.server.bridge.Bridge.access$1900(Bridge.java:68)
> 	at org.jboss.jms.server.bridge.Bridge$BatchTimeChecker.run(Bridge.java:1638)
> 	at java.lang.Thread.run(Thread.java:595)
> As you can see the error is due JMSX properties, actually, because the addMessageIDInHeader sets then in the MQ message (which is not allowed).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:31 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1763) Bisocket
 connection won't be closed if pulling out the ethernet cable between client
 and server. The failure detection code won't close the failure connection,
 as a result,
 the subsequent requests will hang after connection account exceeds the
 threshold
In-Reply-To: <45389628.1258620929702.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <668787316.71193.1311227851634.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1763:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Bisocket connection won't be closed if pulling out the ethernet cable between client and server. The failure detection code won't close the failure connection, as a result, the subsequent requests will hang after connection account exceeds the threshold
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1763
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1763
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Remoting
>    Affects Versions: 1.4.5.GA, 1.4.6.GA
>         Environment: OS: Windows Server 2003. JBoss App Server 4.2.3.GA, JBoss Messaging 1.4.5 GA, JBoss Remoting 2.2.3 SP1 
>            Reporter: mingjun jiang
>            Assignee: Yong Hao Gao
>              Labels: Failure, are, be, by, cable, caused, closed, connection, ethernet, if, manually, out, pulling, they, won't
>             Fix For: 1.4.8.SP3
>
>         Attachments: jboss-test-log  for JBM1.4.5 & Remoting 2.2.3 SP1.zip, QReceiver.java, QSender.java, remoting-bisocket-service.xml
>
>
> We are using JBoss App Server 4.2.3.GA, JBoss Messaging 1.4.5 GA and JBoss Remoting 2.2.3 SP1. In our application, there are a lot of Message listeners running on the client side, these message listeners will receive messages from queue/topic deployed in JBoss Messaging 
> Configuration: 
> We created our own JMS Connection factory which uses the default remoting connector. As you know, the default remoting connector is configured to use the bisocket transport. We didn't change the default value of the remoting connector 
> During we run our application, we open the JBoss web console to monitor the value of currentClientPoolSize under "Jboss.remoting" JMX MBean. 
>   
> How to reproduce this issue: 
> 1. Run 5 message listeners in the client side to receive messages from JBoss Messaging, then we observe the value of currentClientPoolSize is 10 
> 2. After processing several messages, we manually pull out the ethernet cable. The value of currentClientPoolSize is still 10. 
> 3. We run another 5 message listeners in client side, then the value of currentClientPoolSize will become 20 
> 4. After we do the same operations above several times, the value of currentClientPoolSize will increase continuously. Once the value of currentClientPoolSize is equal to the MaxPoolSize, then the subsequent incoming client requests will hang, and we will encounter the following exception in server side 
>        2009-10-20 18:08:09,655 ERROR [org.jboss.remoting.transport.socket.ServerThread] Worker thread initialization failure 
> java.net.SocketException: Connection reset 
>       at java.net.SocketInputStream.read(SocketInputStream.java:168) 
>       at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) 
>       at java.io.BufferedInputStream.read(BufferedInputStream.java:235) 
>       at java.io.FilterInputStream.read(FilterInputStream.java:66) 
>       at org.jboss.remoting.transport.socket.ServerThread.readVersion(ServerThread.java:859) 
>       at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:545) 
>       at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:406) 
>       at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:173) 
> Conclusion: JBoss Messaging won't close the failure connections if they are caused by manually pulling out ethernet cable. As a result, the value of currentClientPoolSize will increase continuously and finally the new client requests will hang 
> Note: If we killed the process of message listener in client side, then the value of currentClientPoolSize will decrease to 0 immediately, it seems that the server could detect the failure connection and perform the corresponding resource releasing. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:32 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1759) JGroups
 cannot process incoming messages during the method execution
In-Reply-To: <1446880455.1258090265888.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <115450313.71211.1311227852226.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1759:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> JGroups cannot process incoming messages during the method execution
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1759
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1759
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07
>         Environment: JBossMessaging-1.4.0_SP3_CP7
>            Reporter: Tyronne Wickramarathne
>            Assignee: Yong Hao Gao
>            Priority: Critical
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> The GroupMember#viewAccepted() takes 31min on the IncomingPacketHandler thread. The JGroups cannot process incoming messages during this method execution. It's completely blocked and leads the following log and subsequent WARNs.
>  2009-11-11 11:50:12.634 [ViewHandler]  WARN [GMS] - failed to collect all ACKs (1) for view [192.168.1.221:49898|2] [192.168.1.221:49898] after 2000ms, missing ACKs from [192.168.1.221:49898] (received=[]), local_addr=192.168.1.221:49898

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:31 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1761) H2 support
In-Reply-To: <1131873002.1258377209944.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1313445335.71204.1311227851998.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1761:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> H2 support
> ----------
>
>                 Key: JBMESSAGING-1761
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1761
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>    Affects Versions: 1.4.3.GA
>            Reporter: Jesper Pedersen
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> In order for the application server to support H2 as the default database we need the necessary persistence-service.xml files.
> H2: http://www.h2database.com/html/main.html
> Please update Branch_5_x and trunk when released.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:32 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1758) Derby support
In-Reply-To: <1622475631.1258040225731.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <817356924.71216.1311227852380.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1758:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Derby support
> -------------
>
>                 Key: JBMESSAGING-1758
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1758
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>    Affects Versions: 1.4.3.GA
>            Reporter: Jesper Pedersen
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.8.SP3
>
>
> In order for the application server to support Derby as the default database we need the necessary persistence-service.xml files.
> Please update Branch_5_x and trunk when released.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:32 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1754) Implement the
 JBossMQ behavior on JBM, when stopDelivery() is invoked via JMX console
In-Reply-To: <1569690620.1256800565753.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <406792094.71221.1311227852584.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1754:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Implement the JBossMQ behavior on JBM, when stopDelivery() is invoked via JMX console
> -------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1754
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1754
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP08
>         Environment: JBoss-EAP-4.3_CP6, JBM-1.4.0-SP3_CP8P1 
>            Reporter: Tyronne Wickramarathne
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> When stopDelivery() is invoked via JMX console for any given MDB, the in process messages are rolled back to their corresponding destination without completing the process. This is however *not* a bug, but the expected behavior in JBM, for this is how it has defined the behavior of stopDelivery(). 
> However on JBossMQ, the in process messages are completed at first, before stopDelivery() is processed. Which means, the call made via stopDelivery() will be kept on hold, until all in process messages are successfully completed. The customers migrating from JBossMQ are seeing this as a compatibility issue, when porting their applications to work on JBM. Hence, would it be possible to accommodate the behavior seen in JBossMQ on JBM please ?
> I have tested this on both JBoss-EAP-4.3_CP6 as well as on JBoss-EAP-4.2_CP7. Both have the same code base for EJB3,JCA but not the JMS provider. Therefore, I'm raising this feature request under JBM.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:32 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1750) Allow
 arbitrary SQL statements for JDBCPersistenceManagerService
In-Reply-To: <620390560.1256620085779.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <652605155.71226.1311227852718.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1750:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Allow arbitrary SQL statements for JDBCPersistenceManagerService
> ----------------------------------------------------------------
>
>                 Key: JBMESSAGING-1750
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1750
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>    Affects Versions: 1.4.0.SP3.CP08
>            Reporter: Justin Bertram
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> Allow arbitrary SQL statements in the SQLProperties field of org.jboss.messaging.core.jmx.JDBCPersistenceManagerService which will be executed just like all the others (e.g. if CreateTablesOnStartup = "true").  I imagine the statements will need to be named according to some pattern (e.g. "CREATE_*").  
> This functionality will allow greater flexibility for our RDBMS support (e.g. a user could configure support for Oracle TimesTen).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:32 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1747)
 ClassNotFoundException while consuming a message in a JMS Queue
In-Reply-To: <558530721.1256073185803.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <993041315.71231.1311227852915.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1747:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> ClassNotFoundException while consuming a message in a JMS Queue
> ---------------------------------------------------------------
>
>                 Key: JBMESSAGING-1747
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1747
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Destination Manager
>    Affects Versions: 1.4.1.GA
>         Environment: Jboss version : 5.0.1 GA
>            Reporter: Stephan Lagraulet
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> We have several JMS queues setup on our jboss server.
> We are using spring to handle the messages.
> When several clients simultaneously post some messages in different queues, the consumer doesn't find the class for the task, ending with this stack trace:
> 2009-07-28 17:10:21,089  WARN [SimpleMessageListenerContainer] [] - Execution of JMS message listener failed
> java.lang.RuntimeException: fr.billetel.interfaces.ws.allotement.business.etatventes.request.CodificationsTaskRequest
>         at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
>         at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:247)
>         at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:279)
>         at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1102)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:772)
>         at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:415)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
>         at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
> We debugged the class org.jboss.messaging.util.OrderedExecutorFactory, and it appears that the class doesn't have the right classloader as it reuses a thread previously setup with an other classloader (the application is packaged in different ears while the queues are defined in deploy), ending in this exception.
> For the moment, we patched the code so that the classloader is reloaded for every call, but it does not seem like a good solution on a long term.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:33 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1744) More
 documented warnings on the usage of JMS selectors
In-Reply-To: <1511528263.1255528386510.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <472861061.71236.1311227853080.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1744:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> More documented warnings on the usage of JMS selectors
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-1744
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1744
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Documentation and Training
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.0.SP3.CP09, 1.4.5.GA
>         Environment: EAP 4.3 CP06 / 1.4.0.SP3-CP08.patch01
>            Reporter: Noel Rocher
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> I'm on-site with a customer who is soon going to production.
> They have designed their application using JMS Selectors on distributed queues.
> We all know this is a broken design but my point is that I think this should be explicitely written in the doc.
> Moreover, GSS is talking about an "unsupported configuration" see case # 348290  (https://enterprise.redhat.com/issue-tracker/?module=issues&action=view&tid=348290). 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:33 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1739) Update to
	JGroup 2.8
In-Reply-To: <1676183430.1254132289202.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <911334565.71240.1311227853273.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1739:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Update to JGroup 2.8
> --------------------
>
>                 Key: JBMESSAGING-1739
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1739
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: AS Integration
>    Affects Versions: 1.4.4.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.8.SP3
>
>
> Also this thread
> http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257080#4257080

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:25 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1880)
 JMSRedelivered not properly set when a client exits without closing the JMS
 resources (connection, session, consumer)
In-Reply-To: <2095350375.277.1308214523819.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <194175709.71100.1311227845544.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1880:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> JMSRedelivered not properly set when a client exits without closing the JMS resources (connection, session, consumer)
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1880
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1880
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.4.0.SP3.CP12, 1.4.8.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> If a client consumer receives a message and exit without acknowledging it or close the connection/session/consumer object, the message will be cancelled at the server side. When the message is delivered, its JMSRedelivered flag should be true.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:25 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1870)
 ClientSocketWrapper constructors have a redundant call to createStreams()
In-Reply-To: <1435766197.10654.1307498099424.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1859627682.71103.1311227845680.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1870:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> ClientSocketWrapper constructors have a redundant call to createStreams()
> -------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1870
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1870
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP12, 1.4.8.GA
>            Reporter: Ron Sigal
>            Assignee: Yong Hao Gao
>            Priority: Minor
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> org.jboss.jms.client.remoting.ClientSocketWrapper is derived from org.jboss.remoting.transport.socket.ClientSocketWrapper.  The constructors of the former look like
>    public ClientSocketWrapper(Socket socket) throws IOException
>    {
>       super(socket);
>       createStreams(socket, null);
>    }
>    public ClientSocketWrapper(Socket socket, Map metadata, Integer timeout) throws Exception
>    {
>       super(socket, metadata, timeout);
>       createStreams(socket, metadata);
>    }
> and the constructors of the latter look like
>    public ClientSocketWrapper(Socket socket) throws IOException
>    {
>       super(socket);
>       createStreams(socket, null);
>    }
>    public ClientSocketWrapper(Socket socket, Map metadata, Integer timeout) throws Exception
>    {
>       super(socket, timeout);
>       createStreams(socket, metadata);
>    }
> The calls to createStreams() in the JBossMessaging versions of ClientSocketWrapper is redundant.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:33 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1735) Paging should
 be taken care in Transactions
In-Reply-To: <678531625.1253096603619.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1656648475.71244.1311227853527.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1735:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Paging should be taken care in Transactions
> -------------------------------------------
>
>                 Key: JBMESSAGING-1735
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1735
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> JBM queues has paging feature to save memory, but in transaction case, messages are stored in the transaction callbacks before it committed to the queue for delivery. So if too many messages are included in one transaction, it may use up memory even paging is turned on.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:33 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1731) Expose the
 JBoss Messaging Cluster partition in JMX
In-Reply-To: <706290811.1251992123859.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1622858341.71250.1311227853864.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1731:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Expose the JBoss Messaging Cluster partition in JMX
> ---------------------------------------------------
>
>                 Key: JBMESSAGING-1731
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1731
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Messaging Core
>    Affects Versions: 1.4.4.GA
>            Reporter: Brad Maxwell
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> Background:
> I have had a request wanting access to the members of the JBoss Messaging Cluster so that they can configure the Recovery plugin without having to hard code hosts in the configuration file.  With the JBoss Messaging Cluster Partition in JMX they would be able to get an accurate list of the members in the Messaging cluster.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:34 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1723) Queue's
 delivering count == -1
In-Reply-To: <773157119.1251244283649.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <762858994.71255.1311227854093.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1723:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Queue's delivering count == -1
> ------------------------------
>
>                 Key: JBMESSAGING-1723
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1723
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.3.GA
>            Reporter: Ondrej Zizka
>            Assignee: Yong Hao Gao
>            Priority: Minor
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>         Attachments: JMS_delivCount_-1.png
>
>
> Delivery count of a queue is sometimes -1. See the picture attached.
> Seen on EAP 5 CR3, Sun JDK 6 for Linux.
> Steps to reproduce:
> 1) Start a client sending messages,
> 2) Start a client receiving messages,
> 3) Watch the stats. If you're lucky enough, you'll see it being -1.
> I haven't found anything about this in the docs:
> http://labs.jboss.com/file-access/default/members/jbossmessaging/freezone/docs/userguide-1.4.4.GA/html/configuration.html#conf.serverpeer.attributes.messagecounters  ( 6.6.2.1 )

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:34 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1718) JMS Queue
 MessageCount attribute isn't increased on message retrieval
In-Reply-To: <1683221009.1250684727188.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1369178051.71260.1311227854245.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1718:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> JMS Queue MessageCount attribute isn't increased on message retrieval
> ---------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1718
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1718
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.3.GA
>            Reporter: Richard Opalka
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.8.SP3
>
>         Attachments: jaxws-samples-dar-jms-client.sar, jaxws-samples-dar-jms.jar
>
>
> We're sending JMS message to the queue and are verifying it was received by checking the JMS Queue MessageCount attribute.
> This used to work on AS 500, AS 501 and AS 510 but doesn't work on AS trunk and AS Branch_5_x.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:34 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1707)
 ConcurrentModificationException in ClientClusteredConnectionFactoryDelegate
In-Reply-To: <410423483.1249981229277.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1138238039.71265.1311227854421.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1707:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> ConcurrentModificationException in ClientClusteredConnectionFactoryDelegate
> ---------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1707
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1707
>             Project: JBoss Messaging
>          Issue Type: Quality Risk
>          Components: JMS Client Manager
>    Affects Versions: 1.4.3.GA
>            Reporter: Pavel Slavicek
>            Assignee: Clebert Suconic
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> I have found ConcurrentModificationException in ClientClusteredConnectionFactoryDelegate.
> Exception in thread "Thread-11" java.util.ConcurrentModificationException
> 	at java.util.WeakHashMap$HashIterator.nextEntry(WeakHashMap.java:784)
> 	at java.util.WeakHashMap$KeyIterator.next(WeakHashMap.java:817)
> 	at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate$FinalizerShutdownHook.run(ClientClusteredConnectionFactoryDelegate.java:414)
> Client:
> client with multiple threads, every thread creates-sends-receives-closes. 
> Problem description:
> Problem is in the ClientClusteredConnectionFactoryDelegate.java in the inner class FinalizerShutdownHook.
> Shutdown hook implementation should to be written as thread safe (see javadoc for addShutdownHook() method). 
> Method run() in the FinalizerShutdownHook class iterates over all elements in the registered delegates 
> but this iteration should be synchronized on the delegates object. 
> Please see http://java.sun.com/javase/6/docs/api/java/util/Collections.html#synchronizedSet%28java.util.Set%29

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:34 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1706) JBoss
 Messaging sometimes causes a HeuristicMixedException
In-Reply-To: <167046771.1249897409362.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1056208905.71274.1311227854864.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1706:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> JBoss Messaging sometimes causes a HeuristicMixedException
> ----------------------------------------------------------
>
>                 Key: JBMESSAGING-1706
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1706
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.4.GA
>            Reporter: Richard Kennard
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>         Attachments: Client_Logs.txt, JBOSS_Server_Logs.txt, remoting-bisocket-service.xml, server.zip
>
>
> I am raising this JIRA to ask the JBoss Messaging Team to take ownership of this issue.
> The issue is that JBM intermittently (ie. when processing large amounts of messages, when bringing up/shutting down nodes in a cluster) throws a HeuristicMixedException. Once it does, that node in the cluster is effectively dead. No more messages get processed. My app has multiple queues, but once one queue on the node fails (say, the e-mail queue) then all queues stop working (say, the reports queues): they all report HeuristicMixedException whenever a messages is sent to them.
> I am using a workaround by having a separate monitoring program that reboots the node whenever it gets stuck in this HeuristicMixedException state.
> The JBoss ESB team have also had to implement a workaround: https://jira.jboss.org/jira/browse/JBESB-2484
> Others on the forum are seeing this too: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4241134#4241134
> According to Kevin Conner of the ESB team, Howard worked with them on a workaround: https://jira.jboss.org/jira/browse/JBPAPP-1642, but the issue persists.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:35 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1684) Message
 remain in the queue and do not get dispatched
In-Reply-To: <1603937672.1247553629290.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1661868676.71280.1311227855105.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1684:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Message remain in the queue and do not get dispatched
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-1684
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1684
>             Project: JBoss Messaging
>          Issue Type: Quality Risk
>          Components: JMS Facade
>    Affects Versions: 1.4.3.GA
>         Environment: SuSe Linux Enterprise Server 10, Java 1.5.0_11, AS 5 with JBoss Messaging - default installation
>            Reporter: Alexander Marktl
>            Assignee: Yong Hao Gao
>            Priority: Minor
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>         Attachments: jms-provider-evaluation.zip
>
>
> I tried to create 10 queues and send 10.000 messages per queue from a single producer per queue to a single consumer per queue. Unfortunately  not all of the messages where delivered, some messages remain in the queues and wait for delivery. The JMX console for example states: 3 messages in the queue, 3 messages pending for delivery. But nothing happens. My receivers don't get these last messages. I don't know if this is a configuration issue or a bug. 
> The queues are named: qname_0 ...qname_n

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:35 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1661) Messages in
 JBoss 5.1 that use bridging get stuck in a devlivering mode and are not
 sent to the remote cluster
In-Reply-To: <29236051.1245359337536.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <461907643.71285.1311227855417.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1661:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Messages in JBoss 5.1 that use bridging get stuck in a devlivering mode and are not sent to the remote cluster
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1661
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1661
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.3.GA
>         Environment: Linux -- JBoss 5.1 GA / JBM 1.4.3GA / Remoting 2.5.1
>            Reporter: Peter Crossley
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.8.SP3
>
>
> A Message bridge between to clusters will get in to a state where the messages will not be picked up by the bridge on the topic/queue and remain in the "delivering" counter until the bridge is restarted via the JMX console or by restarting the Jboss instance.
> I attempted to use JBM 1.4.4 which has a fix (JBMESSAGING-1456) that seems to be the same issue, though do to the difference in the remoting I cannot use the 1.4.4 GA release.
> Can we get the fixes that were applied to the 1.4.4 release in a usable build for JBoss AS 5.1

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:35 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1648) Bridge may
 stop working after long time idle
In-Reply-To: <30049000.1244716497603.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <504943232.71290.1311227855572.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1648:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Bridge may stop working after long time idle
> --------------------------------------------
>
>                 Key: JBMESSAGING-1648
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1648
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.4.3.GA
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.8.SP3
>
>
> Bridge service may stop working after a long time idle

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:35 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1631) Messages are
 piling up in the queues in clustered environment and not pulled by message
 sucker
In-Reply-To: <30545717.1242929996483.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1652460473.71298.1311227855929.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1631:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Messages are piling up in the queues in clustered environment and not pulled by message sucker
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1631
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1631
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP08
>         Environment: Cluster of a few JBoss 4.2.3 servers with JBM 1.4.2.GA-SP1 or 1.4.0.SP3_CP08 running on x64 windows servers.
> JBoss Remoting 2.5.1 or 2.2.3
> Clustered XA connection factory, clustered queues, both server and client (MDBs) are deployed as one application - identical deployment for all servers in a cluster
>            Reporter: Victor Starenky
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>         Attachments: 1631-test-source.zip, logs-and-config-prod.zip, logs-and-config-test.zip, TestRecommendationSentProcessorMDB.java
>
>
> We have an EJB3 application is running on a cluster of 7 servers. 
> All servers have the same application farmed across them. 
> We have a clustered queue and using clustered connection factory.
> Originally we ran into the bug JBMESSAGING-1456 and while testing the fix ran into a different problem. After the cluster was running for some time (usually overnight with lots of heavy background processing hapenning at that time) we see messages are "piling up" in some queues on some nodes.
> Sympthoms are:
> MessageCount is not zero (rather in the order of hundreeds), DeliveringCount is zero. These nodes have ConsumerCount=0 for the queues experiencing the problem. Message sucker is configured as far as I can tell. Looks like the problem might be related to client and/or server failover leaving some nodes without consumers while sucker not doing it's job (if I understand it correctly). 
> Once we bump the timeout values much higher than they are in the original config files the problem seems to disappear or at least show up much less frequently. Specifically I'm talking about these values:
> messaging-service.xml:
>       <attribute name="FailoverStartTimeout">180000</attribute>
> remoting-bisocket-service.xml:
>                <attribute name="clientLeasePeriod" isParam="true">30000</attribute>
>                <attribute name="validatorPingPeriod" isParam="true">30000</attribute>
>                <attribute name="validatorPingTimeout" isParam="true">20000</attribute>
>                <attribute name="registerCallbackListener">false</attribute>
>                <attribute name="timeout" isParam="true">240000</attribute>
> While this serves as a temporary workaround we don't feel we can rely on JBM in a production clustered environment without having failover working properly.
> This is a big showstopper for us at the moment.
> Attached are the log files from the prod environment of 7 servers with the config files as well as log files from the test environment with just 2 servers (having same issue) and corresponding configs. The logs were produced by the test version of the messaging code with added logging as per JBMESSAGING-1456.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:36 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1621) Provide
 complete message ordering in a clustered environment
In-Reply-To: <16554562.1242110266630.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <441394681.71303.1311227856187.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1621:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Provide complete message ordering in a clustered environment
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-1621
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1621
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP08, 1.4.4.GA
>            Reporter: Yusuke Yamamoto
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> While JBMESSAGING-1416 states message ordering feature in a singleton configuration, customer is also requesting a complete message ordering feature which is applicable in a clustered environment.
> Here's the background:
> In the case JMS is used, both performance and scalability are priority.
> There is a conflict between scalable JMS implementation and complete message ordering feature since order aware messages cannot be processed concurrently.
> But order unaware queues should be still processed in parallel for better throughput.
> Additionally, there are some cases that no downtime is acceptable. But HA-Singleton requires certain amount of time to fail-over the service to other node.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:36 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1619) add example
 TCP cluster configuration
In-Reply-To: <8236548.1241645807005.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <172741065.71309.1311227856405.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1619:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> add example TCP cluster configuration
> -------------------------------------
>
>                 Key: JBMESSAGING-1619
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1619
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP07
>            Reporter: Dennis Reed
>            Assignee: Tyronne Wickramarathne
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> Add an example TCP cluster configuration (commented out) to all the example *-persistence-service.xml files.
> This will make it easier for users who have issues with UDP multicast to configure it to use TCP clustering.
> (The same thing is being done to all the EAP configurations that don't already include this). 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:36 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1615) Programmatic
 way to check the state of a topic
In-Reply-To: <22443752.1241518126593.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1145784687.71315.1311227856629.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1615:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Programmatic way to check the state of a topic
> ----------------------------------------------
>
>                 Key: JBMESSAGING-1615
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1615
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>    Affects Versions: 1.4.1.GA
>            Reporter: Colin Mondesir
>            Assignee: Yong Hao Gao
>            Priority: Minor
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> When the deployTopic(String, String) method is called we have found there is a slight delay before the topic is available to create MessageConsumer.
> Is there a programmatic way of checking the state that the topic is in, so that we don't have to wait an arbitrary period of time before creating the Consumer?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:36 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1610) expose
 jbossInternalLifecycle method on jms destination mbeans
In-Reply-To: <27082798.1240932886857.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1380054648.71320.1311227856811.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1610:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> expose jbossInternalLifecycle method on jms destination mbeans
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-1610
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1610
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: AS Integration
>    Affects Versions: 1.4.3.GA
>            Reporter: Emanuel Muckenhuber
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> Currently the Queue and Topic xmbean definitions don't expose the jbossInternalLifecycle(String method). This method is needed that the lifecycle and state changes of a mbean are handled by microcontainer (AS5). Otherwise profileservice cannot determine the current state and a stopped jms destination would be still exposed as running to JON/JOPR.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:37 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1594) Provide
 support for a List of Strings (in StreamMessage) with a size > 64K
In-Reply-To: <19407645.1239259282444.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <326939520.71325.1311227857007.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1594:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Provide support for a List of Strings (in StreamMessage) with a size > 64K
> --------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1594
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1594
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3
>            Reporter: Colin Mondesir
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> Looking at the code, there is support for 'longstring' for java.lang.String. But that doesn't happen for a List of Strings.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:37 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1517) Malformed
 HTTP POST from Post Office management page in JMX Console
In-Reply-To: <22517353.1235529104697.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <216918210.71330.1311227857261.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1517:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Malformed HTTP POST from Post Office management page in JMX Console
> -------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1517
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1517
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP03, 1.4.2.GA.SP1
>         Environment: All
>            Reporter: Paul Kaiser
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> When trying to submit changes to the configuration of the Messaging Post Office from the JMX Console interface, the improper quoting of configuration strings results in an improper HTTP POST. This prevents the submission of any updates to the component.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:37 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1513) Database
 maintenance scripts
In-Reply-To: <19858050.1234906484708.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <37133629.71335.1311227857401.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1513:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Database maintenance scripts
> ----------------------------
>
>                 Key: JBMESSAGING-1513
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1513
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Configuration and Management
>    Affects Versions: 1.4.2.GA.SP1
>            Reporter: Len DiMaggio
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> Project JIRA for SOA-P platform JIRA: https://jira.jboss.org/jira/browse/SOA-310

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:37 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1491) add support
 for Ingres RDBMS to JBoss Messaging
In-Reply-To: <22555123.1232348524540.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1325832440.71341.1311227857776.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1491:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> add support for Ingres RDBMS to JBoss Messaging
> -----------------------------------------------
>
>                 Key: JBMESSAGING-1491
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1491
>             Project: JBoss Messaging
>          Issue Type: Patch
>    Affects Versions: 1.4.0.SP3.CP06, 2.0.0 Beta1, EAP/SOA-P Integration, 1.4.3.GA, Unscheduled, AS 5.0 Integration
>         Environment: N/A
>            Reporter: murray armfield
>            Assignee: Yong Hao Gao
>            Priority: Minor
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>         Attachments: ingres-persistence-service.newrev.xml, ingres-persistence-service.xml, ingres-persistence-service.xml, ingres.diff, ingresv2.diff
>
>   Original Estimate: 30 minutes
>  Remaining Estimate: 30 minutes
>
> I've been working on JBoss support on Ingres.
> I've written an ingres-persistence-service.xml file for use with Ingres for inclusion as part of JBoss Messaging

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:37 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1490) BridgeService
 should be JAAS aware
In-Reply-To: <12562631.1232152144349.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1440584133.71346.1311227857973.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1490:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> BridgeService should be JAAS aware
> ----------------------------------
>
>                 Key: JBMESSAGING-1490
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1490
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>    Affects Versions: 1.4.2.GA
>         Environment: n/a
>            Reporter: Nicholas Sayer
>            Assignee: Yong Hao Gao
>            Priority: Optional
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> org.jboss.jms.server.bridge.BridgeService currently requires a username and password for the source and destination. It would be better if it could be configured with a JAAS login context name. This would allow username and password information to be set in, for example, a SecureIdentityLoginModule. For example:
>     <application-policy name = "JmsBridgeRealm">
>        <authentication>
>           <login-module code = "org.jboss.resource.security.SecureIdentityLoginModule" flag = "required">
>              <module-option name = "principal">${bridge.user}</module-option>
>              <module-option name = "userName">${bridge.user}</module-option>
>              <module-option name = "password">${bridge.encryptedPassword}</module-option>
>              <module-option name = "ignoreMissigingMCF">true</module-option>
> <!-- it is a separate bug that you must set managedConnectionFactoryName to something regardless of setting ignoreMissingMCF to true -->
>              <module-option name = "managedConnectionFactoryName">jboss.nonexistent:service=NonExistent,name=NonExistent</module-option>
>           </login-module>
>        </authentication>
>     </application-policy>
> There is undoubtedly a better way to accomplish this (probably to pass the JAAS context directly into the JMS connection factory used to vend connections for the bridge), but we're using this as a crude hack for now:
> import java.util.Set;
> import javax.security.auth.Subject;
> import javax.security.auth.login.LoginContext;
> import javax.security.auth.login.LoginException;
> import javax.security.auth.login.CredentialNotFoundException;
> import javax.resource.spi.security.PasswordCredential;
> import org.jboss.jms.server.bridge.BridgeService;
> public class JAASAwareBridgeService extends BridgeService {
>         private String sourceContext, targetContext;
>         public void setSourceLoginContext(String ctxName) { this.sourceContext = ctxName; }
>         public String getSourceLoginContext() { return this.sourceContext; }
>         public void setTargetLoginContext(String ctxName) { this.targetContext = ctxName; }
>         public String getTargetLoginContext() { return this.targetContext; }
>         public void start() throws Exception {
>                 setupSourceCredentials();
>                 setupTargetCredentials();
>                 super.start();
>         }
>         private void setupSourceCredentials() throws LoginException {
>                 PasswordCredential pc = getPasswordCredential(this.sourceContext);
>                 super.setSourceUsername(pc.getUserName());
>                 super.setSourcePassword(new String(pc.getPassword()));
>          }
>         private void setupTargetCredentials() throws LoginException {
>                 PasswordCredential pc = getPasswordCredential(this.targetContext);
>                 super.setTargetUsername(pc.getUserName());
>                 super.setTargetPassword(new String(pc.getPassword()));
>         }
>         private static PasswordCredential getPasswordCredential(String contextName) throws LoginException {
>                 LoginContext ctx = new LoginContext(contextName);
>                 ctx.login();
>                 Subject s = ctx.getSubject();
>                 Set<PasswordCredential> creds = s.getPrivateCredentials(PasswordCredential.class);
>                 if (creds.isEmpty())
>                         throw new CredentialNotFoundException("Login context '" + contextName + "' subject has no PasswordCredential");
>                 return creds.iterator().next(); // get 1st
>         }
> }

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:38 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1478) inconsistent
 test suite performance
In-Reply-To: <25748306.1231170954442.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <310829818.71351.1311227858209.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1478:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> inconsistent test suite performance
> -----------------------------------
>
>                 Key: JBMESSAGING-1478
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1478
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Tests and Performance
>    Affects Versions:  1.4.0.SP3.CP04
>            Reporter: Aleksandar Kostadinov
>            Assignee: Yong Hao Gao
>              Labels: isolation, performance, testsuite
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> I see inconsistent performance running the JBM test suite. Here I have 2 builds on the same physical machine (windows), using local disk storage so environment should be pretty stable.
> The mysql database is shared but I doubt it is the culprit. 
> I run the test suite with the following options:
> property( name: "functional.tests.database", value: dbname )
> property( name: "stress.tests.database", value: dbname )
> property( name: "clustering.tests.database", value: dbname )
> property( name: "test.target", value: "report" )
> property( name: "test.bind.address", value: properties["env.MYTESTIP_1"] )
> property( name: "jboss.messaging.groupname", value: properties["env.BUILD_TAG"])                                                                               
> property( name: "jboss.messaging.datachanneludpaddress", value: properties["env.MCAST_ADDR"] )
> property( name: "jboss.messaging.controlchanneludpaddress", value: properties["env.MCAST_ADDR"] )
> Are there any other options I can add to increase isolation from other processes in the same LAN?
> Would you be able to look at these 2 builds and based on the logs, say why is the first one taking longer and eventually timeout?
> http://hudson.qa.jboss.com/hudson/view/SOA-Release/job/soa-jbm/163/
> http://hudson.qa.jboss.com/hudson/view/SOA-Release/job/soa-jbm/164/

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:38 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1462) Message
 expiration is not correctly managed
In-Reply-To: <32621692.1228481866881.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30635930.71356.1311227858431.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1462:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Message expiration is not correctly managed
> -------------------------------------------
>
>                 Key: JBMESSAGING-1462
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1462
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.1.GA
>         Environment: JBAS 5.0GA, JBM 1.4.1GA, persistence on Oracle 10i
>            Reporter: Ivan
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>         Attachments: JBMESSAGING-1462.java
>
>
> 1) A topic is created 
> 2) A durable subscriber is created fro the topic 
> 3) A message is sent on the topic 
> 4) The durable subscriber pulls the message from the topic ( receive() ) but don't ack 
> 5) The durable subscriber is closed, subscriber session.unsuscribe(name) is called but an exception is thrown and then the subsciber session is closed. 
> As result of this a message, expired, with DELIVERY_COUNT = 1 will remain on the database forever. 
> The stacktrace of the exception thrown: 
> java.lang.IllegalStateException: Cannot remove references while deliveries are in progress (Channel 521), there are 1
>         at org.jboss.messaging.core.impl.ChannelSupport.removeAllReferences(ChannelSupport.java:394)
>         at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.internalRemoveBinding(MessagingPostOffice.java:1939)
>         at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.removeBinding(MessagingPostOffice.java:474)
>         at org.jboss.jms.server.endpoint.ServerSessionEndpoint.unsubscribe(ServerSessionEndpoint.java:829)
>         at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$unsubscribe$aop(SessionAdvised.java:135)
>         at org.jboss.jms.server.endpoint.advised.SessionAdvised$unsubscribe_8775578479443985821.invokeTarget(SessionAdvised$unsubscribe_8775578479443985821.java)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
>         at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
>         at org.jboss.jms.server.endpoint.advised.SessionAdvised.unsubscribe(SessionAdvised.java)
>         at org.jboss.jms.wireformat.SessionUnsubscribeRequest.serverInvoke(SessionUnsubscribeRequest.java:74)
>         at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:143)
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
>         at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
>         at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
>         at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:549)
>         at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:38 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1401) Unverified:
 Restarting a Queue will delete persistent messages in the queue.
In-Reply-To: <1348241.1216341592381.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <589974767.71361.1311227858664.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1401:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> Unverified: Restarting a Queue will delete persistent messages in the queue.
> ----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1401
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1401
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.4.0.SP3
>            Reporter: Jay Howell
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> Restarting a queue in a running server will delete persistent messages out of the database.  This bug was found while troubleshooting a case.  When a customer restarted the queues, they noticed that all of the persistent messages in the database were gone.  I have yet to verify this and will verify as soon as possible.  I wanted to make sure that I didn't forget to put it in.  So at this point this is an unverified bug. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 01:57:39 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 21 Jul 2011 01:57:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1287) SOA-P test
	suite failures
In-Reply-To: <23570323.1210850002522.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <732677908.71366.1311227859129.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1287:
--------------------------------------

    Fix Version/s: 1.4.8.SP3
                       (was: 1.4.8.SP2)


> SOA-P test suite failures
> -------------------------
>
>                 Key: JBMESSAGING-1287
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1287
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.0.SP3_CP01
>            Reporter: Aleksandar Kostadinov
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> I'm running the JBM test suite against the binaries in the SOA-P Platform 4.2 CP01. I see 4 failures. 
>     * TEST-org.jboss.test.messaging.jms.bridge.BridgeTest-Remote-bisocket.xml.
>     * org.jboss.test.messaging.jms.clustering.MultipleFailoverTest(Clustering).testFailoverFloodTwoServers
>     * org.jboss.test.messaging.jms.clustering.NoFailoverTest(Clustering).testCrashNoFailover
>     * org.jboss.test.messaging.jms.ManifestTest.testManifestEntries
> Failure details in here http://hudson.qa.jboss.com/hudson/job/jboss-soa-platform-JBM-testsuite/73/testReport/
> 3 of the failures are timeout (see console log for BridgeTest). We are running on a 2 CPU DualCore physical machine so system speed should not be an issue. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 03:40:23 2011
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Thu, 21 Jul 2011 03:40:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1323) @Resource injection
 on WebServiceContext fails
In-Reply-To: <48156148.61562.1311039863763.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <884214573.71578.1311234023647.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano resolved AS7-1323.
----------------------------------

    Resolution: Rejected


OK, thanks. Solving as rejected, given this was not a bug in the end.

> @Resource injection on WebServiceContext fails
> ----------------------------------------------
>
>                 Key: AS7-1323
>                 URL: https://issues.jboss.org/browse/AS7-1323
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>         Environment: Ubuntu 11.04 64 bit, Sun Java 1.6.0_26, JBoss AS 7.0.0.Final
>            Reporter: Abhijit Sarkar
>            Assignee: Alessio Soldano
>
> 00:20:55,004 WARN  [org.jboss.as.ee.component.ResourceInjectionAnnotationParsingProcessor] (MSC service thread 1-4) Can't handle @Resource for ENC name: MovieServiceRestful/wsCtx on class MovieServiceRestful since it's missing a "lookup" (or "mappedName") value and isn't of any known type.
> @WebServiceProvider
> @BindingType(value = HTTPBinding.HTTP_BINDING)
> public class MovieServiceRestful implements Provider<Source> {
>     @Resource
>     protected WebServiceContext wsCtx;
>     ...
> }

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 04:10:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 21 Jul 2011 04:10:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-9420) JMS Manager is
 unavailable in JBoss Application Server 6.1.0
In-Reply-To: <254669353.69334.1311169405483.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <80132823.71625.1311235824380.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBAS-9420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved JBAS-9420.
--------------------------------

    Fix Version/s: 6.1.0
       Resolution: Done


Fixed in r111808.

> JMS Manager is unavailable in JBoss Application Server 6.1.0
> ------------------------------------------------------------
>
>                 Key: JBAS-9420
>                 URL: https://issues.jboss.org/browse/JBAS-9420
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (HornetQ), Web Console
>    Affects Versions: 6.1.0
>         Environment: Windows XP SP 3
>            Reporter: Jarod Rose
>            Assignee: Clebert Suconic
>              Labels: jboss, jms
>             Fix For: 6.1.0
>
>
> When accessing the Administration Console in JBoss 6.1.0-SNAPSHOT the JMS Manager is unavailable.  When inspecting the log the following stack trace can be found.
> 2011-07-20 09:21:38,797 INFO  [org.rhq.core.pc.inventory.RuntimeDiscoveryExecutor] (InventoryManager.discovery-1) Scanned [0] servers and found [0] total descendant Resources.
> 2011-07-20 09:21:38,812 INFO  [org.rhq.core.pc.inventory.RuntimeDiscoveryExecutor] (InventoryManager.discovery-1) Running runtime discovery scan rooted at [platform]
> 2011-07-20 09:21:38,922 WARN  [org.rhq.core.pc.inventory.InventoryManager] (InventoryManager.discovery-1) Failure during discovery for [JMS Manager] Resources - failed after 0 ms.: java.lang.Exception: Discovery component invocation failed.
> 	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:283) [:3.0.0]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_20]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_20]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_20]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_20]
> 	at java.lang.Thread.run(Thread.java:619) [:1.6.0_20]
> Caused by: java.lang.reflect.UndeclaredThrowableException: Failed to invoke method 'getVersion' on component 'JMSServerMO' with parameters [].
> 	at org.jboss.profileservice.plugins.management.util.AbstractManagedComponentRuntimeDispatcher.invoke(AbstractManagedComponentRuntimeDispatcher.java:148) [:0.2.2]
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.invoke(DelegatingComponentDispatcherImpl.java:93) [:0.2.2]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_20]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_20]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
> 	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121) [jboss-aop.jar:2.2.1.GA]
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82) [:1.0.1.GA]
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99) [:6.1.0-SNAPSHOT]
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:967) [:]
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106) [:]
> 	at org.jboss.remoting.Client.invoke(Client.java:2070) [:]
> 	at org.jboss.remoting.Client.invoke(Client.java:879) [:]
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60) [:1.0.1.GA]
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74) [:1.0.1.GA]
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65) [:1.0.1]
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
> 	at org.jboss.aop.generatedproxies.AOPProxy$0.invoke(AOPProxy$0.java) [:]
> 	at org.jboss.profileservice.management.client.ManagedOperationDelegate.invoke(ManagedOperationDelegate.java:63) [:6.1.0-SNAPSHOT]
> 	at org.jboss.as.integration.hornetq.jopr.JMSManagerDiscoveryComponent.getVersion(JMSManagerDiscoveryComponent.java:74)
> 	at org.jboss.as.integration.hornetq.jopr.JMSManagerDiscoveryComponent.discoverResources(JMSManagerDiscoveryComponent.java:48)
> 	at sun.reflect.GeneratedMethodAccessor358.invoke(Unknown Source) [:1.6.0_20]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
> 	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
> 	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:279) [:3.0.0]
> 	... 5 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.integration.hornetq.management.jms.JMSManageMO.getJmsServerControl(JMSManageMO.java:128) [:6.1.0-SNAPSHOT]
> 	at org.jboss.as.integration.hornetq.management.jms.JMSServerMO.getVersion(JMSServerMO.java:47) [:6.1.0-SNAPSHOT]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_20]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_20]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
> 	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:60) [jboss-reflect.jar:2.2.1.SP1]
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.1.SP1]
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) [jboss-reflect.jar:2.2.1.SP1]
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300) [jboss-reflect.jar:2.2.1.SP1]
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:305) [jboss-kernel.jar:2.2.0.SP1]
> 	at org.jboss.kernel.plugins.registry.basic.LifecycleAwareKernelBus$1.dispatch(LifecycleAwareKernelBus.java:61) [jboss-kernel.jar:2.2.0.SP1]
> 	at org.jboss.kernel.plugins.registry.basic.LifecycleAwareKernelBus$1.dispatch(LifecycleAwareKernelBus.java:58) [jboss-kernel.jar:2.2.0.SP1]
> 	at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:71) [jboss-kernel.jar:2.2.0.SP1]
> 	at org.jboss.kernel.plugins.registry.basic.LifecycleAwareKernelBus.invoke(LifecycleAwareKernelBus.java:57) [jboss-kernel.jar:2.2.0.SP1]
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.invoke(KernelBusRuntimeComponentDispatcher.java:85) [:0.2.2]
> 	at org.jboss.profileservice.plugins.management.util.AbstractManagedComponentRuntimeDispatcher.invoke(AbstractManagedComponentRuntimeDispatcher.java:135) [:0.2.2]
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.invoke(DelegatingComponentDispatcherImpl.java:93) [:0.2.2]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_20]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_20]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
> 	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121) [jboss-aop.jar:2.2.1.GA]
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82) [:1.0.1.GA]
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99) [:6.1.0-SNAPSHOT]
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:967) [:]
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106) [:]
> 	at org.jboss.remoting.Client.invoke(Client.java:2070) [:]
> 	at org.jboss.remoting.Client.invoke(Client.java:879) [:]
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60) [:1.0.1.GA]
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74) [:1.0.1.GA]
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65) [:1.0.1]
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
> 	at org.jboss.aop.generatedproxies.AOPProxy$0.invoke(AOPProxy$0.java) [:]
> 	at org.jboss.profileservice.management.client.ManagedOperationDelegate.invoke(ManagedOperationDelegate.java:63) [:6.1.0-SNAPSHOT]
> 	at org.jboss.as.integration.hornetq.jopr.JMSManagerDiscoveryComponent.getVersion(JMSManagerDiscoveryComponent.java:74)
> 	at org.jboss.as.integration.hornetq.jopr.JMSManagerDiscoveryComponent.discoverResources(JMSManagerDiscoveryComponent.java:48)
> 	at sun.reflect.GeneratedMethodAccessor358.invoke(Unknown Source) [:1.6.0_20]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
> 	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
> 	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:279) [:3.0.0]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_20]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_20]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_20]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_20]
> 	at java.lang.Thread.run(Thread.java:619) [:1.6.0_20]
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72) [:1.0.1.GA]
> 	... 18 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 04:14:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 21 Jul 2011 04:14:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-9420) JMS Manager is
 unavailable in JBoss Application Server 6.1.0
In-Reply-To: <254669353.69334.1311169405483.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1089614513.71630.1311236063794.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBAS-9420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai reassigned JBAS-9420:
----------------------------------

    Assignee: jaikiran pai  (was: Clebert Suconic)


> JMS Manager is unavailable in JBoss Application Server 6.1.0
> ------------------------------------------------------------
>
>                 Key: JBAS-9420
>                 URL: https://issues.jboss.org/browse/JBAS-9420
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (HornetQ), Web Console
>    Affects Versions: 6.1.0
>         Environment: Windows XP SP 3
>            Reporter: Jarod Rose
>            Assignee: jaikiran pai
>              Labels: jboss, jms
>             Fix For: 6.1.0
>
>
> When accessing the Administration Console in JBoss 6.1.0-SNAPSHOT the JMS Manager is unavailable.  When inspecting the log the following stack trace can be found.
> 2011-07-20 09:21:38,797 INFO  [org.rhq.core.pc.inventory.RuntimeDiscoveryExecutor] (InventoryManager.discovery-1) Scanned [0] servers and found [0] total descendant Resources.
> 2011-07-20 09:21:38,812 INFO  [org.rhq.core.pc.inventory.RuntimeDiscoveryExecutor] (InventoryManager.discovery-1) Running runtime discovery scan rooted at [platform]
> 2011-07-20 09:21:38,922 WARN  [org.rhq.core.pc.inventory.InventoryManager] (InventoryManager.discovery-1) Failure during discovery for [JMS Manager] Resources - failed after 0 ms.: java.lang.Exception: Discovery component invocation failed.
> 	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:283) [:3.0.0]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_20]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_20]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_20]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_20]
> 	at java.lang.Thread.run(Thread.java:619) [:1.6.0_20]
> Caused by: java.lang.reflect.UndeclaredThrowableException: Failed to invoke method 'getVersion' on component 'JMSServerMO' with parameters [].
> 	at org.jboss.profileservice.plugins.management.util.AbstractManagedComponentRuntimeDispatcher.invoke(AbstractManagedComponentRuntimeDispatcher.java:148) [:0.2.2]
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.invoke(DelegatingComponentDispatcherImpl.java:93) [:0.2.2]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_20]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_20]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
> 	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121) [jboss-aop.jar:2.2.1.GA]
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82) [:1.0.1.GA]
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99) [:6.1.0-SNAPSHOT]
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:967) [:]
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106) [:]
> 	at org.jboss.remoting.Client.invoke(Client.java:2070) [:]
> 	at org.jboss.remoting.Client.invoke(Client.java:879) [:]
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60) [:1.0.1.GA]
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74) [:1.0.1.GA]
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65) [:1.0.1]
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
> 	at org.jboss.aop.generatedproxies.AOPProxy$0.invoke(AOPProxy$0.java) [:]
> 	at org.jboss.profileservice.management.client.ManagedOperationDelegate.invoke(ManagedOperationDelegate.java:63) [:6.1.0-SNAPSHOT]
> 	at org.jboss.as.integration.hornetq.jopr.JMSManagerDiscoveryComponent.getVersion(JMSManagerDiscoveryComponent.java:74)
> 	at org.jboss.as.integration.hornetq.jopr.JMSManagerDiscoveryComponent.discoverResources(JMSManagerDiscoveryComponent.java:48)
> 	at sun.reflect.GeneratedMethodAccessor358.invoke(Unknown Source) [:1.6.0_20]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
> 	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
> 	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:279) [:3.0.0]
> 	... 5 more
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.integration.hornetq.management.jms.JMSManageMO.getJmsServerControl(JMSManageMO.java:128) [:6.1.0-SNAPSHOT]
> 	at org.jboss.as.integration.hornetq.management.jms.JMSServerMO.getVersion(JMSServerMO.java:47) [:6.1.0-SNAPSHOT]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_20]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_20]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
> 	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
> 	at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:60) [jboss-reflect.jar:2.2.1.SP1]
> 	at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.1.SP1]
> 	at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) [jboss-reflect.jar:2.2.1.SP1]
> 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:300) [jboss-reflect.jar:2.2.1.SP1]
> 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:305) [jboss-kernel.jar:2.2.0.SP1]
> 	at org.jboss.kernel.plugins.registry.basic.LifecycleAwareKernelBus$1.dispatch(LifecycleAwareKernelBus.java:61) [jboss-kernel.jar:2.2.0.SP1]
> 	at org.jboss.kernel.plugins.registry.basic.LifecycleAwareKernelBus$1.dispatch(LifecycleAwareKernelBus.java:58) [jboss-kernel.jar:2.2.0.SP1]
> 	at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:71) [jboss-kernel.jar:2.2.0.SP1]
> 	at org.jboss.kernel.plugins.registry.basic.LifecycleAwareKernelBus.invoke(LifecycleAwareKernelBus.java:57) [jboss-kernel.jar:2.2.0.SP1]
> 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.invoke(KernelBusRuntimeComponentDispatcher.java:85) [:0.2.2]
> 	at org.jboss.profileservice.plugins.management.util.AbstractManagedComponentRuntimeDispatcher.invoke(AbstractManagedComponentRuntimeDispatcher.java:135) [:0.2.2]
> 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.invoke(DelegatingComponentDispatcherImpl.java:93) [:0.2.2]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_20]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_20]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
> 	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121) [jboss-aop.jar:2.2.1.GA]
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82) [:1.0.1.GA]
> 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99) [:6.1.0-SNAPSHOT]
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:967) [:]
> 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106) [:]
> 	at org.jboss.remoting.Client.invoke(Client.java:2070) [:]
> 	at org.jboss.remoting.Client.invoke(Client.java:879) [:]
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60) [:1.0.1.GA]
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
> 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74) [:1.0.1.GA]
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65) [:1.0.1]
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.GA]
> 	at org.jboss.aop.generatedproxies.AOPProxy$0.invoke(AOPProxy$0.java) [:]
> 	at org.jboss.profileservice.management.client.ManagedOperationDelegate.invoke(ManagedOperationDelegate.java:63) [:6.1.0-SNAPSHOT]
> 	at org.jboss.as.integration.hornetq.jopr.JMSManagerDiscoveryComponent.getVersion(JMSManagerDiscoveryComponent.java:74)
> 	at org.jboss.as.integration.hornetq.jopr.JMSManagerDiscoveryComponent.discoverResources(JMSManagerDiscoveryComponent.java:48)
> 	at sun.reflect.GeneratedMethodAccessor358.invoke(Unknown Source) [:1.6.0_20]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
> 	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
> 	at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:279) [:3.0.0]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_20]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_20]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_20]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_20]
> 	at java.lang.Thread.run(Thread.java:619) [:1.6.0_20]
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72) [:1.0.1.GA]
> 	... 18 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 04:18:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 21 Jul 2011 04:18:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-9418) Upgrade HornetQ to
	2.2.5.Final
In-Reply-To: <59090345.58628.1310861243700.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1757637427.71642.1311236303778.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBAS-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai reassigned JBAS-9418:
----------------------------------

    Assignee: jaikiran pai  (was: Clebert Suconic)


> Upgrade HornetQ to 2.2.5.Final
> ------------------------------
>
>                 Key: JBAS-9418
>                 URL: https://issues.jboss.org/browse/JBAS-9418
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: JMS (HornetQ)
>    Affects Versions: 6.0.0.Final
>            Reporter: Luis Conceicao
>            Assignee: jaikiran pai
>             Fix For: 6.1.0
>
>
> Upgrade HornetQ to 2.2.5.Final

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 04:20:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 21 Jul 2011 04:20:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-9418) Upgrade HornetQ to
	2.2.5.Final
In-Reply-To: <59090345.58628.1310861243700.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <713276930.71646.1311236423725.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBAS-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved JBAS-9418.
--------------------------------

    Resolution: Done


Done in r111807.

> Upgrade HornetQ to 2.2.5.Final
> ------------------------------
>
>                 Key: JBAS-9418
>                 URL: https://issues.jboss.org/browse/JBAS-9418
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Component  Upgrade
>      Security Level: Public(Everyone can see) 
>          Components: JMS (HornetQ)
>    Affects Versions: 6.0.0.Final
>            Reporter: Luis Conceicao
>            Assignee: jaikiran pai
>             Fix For: 6.1.0
>
>
> Upgrade HornetQ to 2.2.5.Final

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 04:26:23 2011
From: jira-events at lists.jboss.org (Marco Piraccini (JIRA))
Date: Thu, 21 Jul 2011 04:26:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2289) Support JPA
 Resource Local EntityTransaction based Transactions
In-Reply-To: <55528903.1254891769970.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1386110331.71669.1311236783766.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615582#comment-12615582 ] 

Marco Piraccini commented on JBRULES-2289:
------------------------------------------

It's really impossible to support RESOURCE_LOCAL? That can be quite a problem in cases when JTA is not supported. 
That issue is probably related to that one I met with JBPM: https://issues.jboss.org/browse/JBPM-3282

> Support JPA Resource Local EntityTransaction based Transactions
> ---------------------------------------------------------------
>
>                 Key: JBRULES-2289
>                 URL: https://issues.jboss.org/browse/JBRULES-2289
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.0.1.FINAL
>            Reporter: Michael Youngstrom
>            Assignee: Mark Proctor
>
> It would be nice if wherever JPA is used in Drools (drools-flow in particular) there was support for RESOURCE_LOCAL transactions through JPA's EntityTransaction interface as an alternative to JTA.
> Support for resource local transactions would reduce the base Drools Flow dependency footprint (no need for bitronix) as well as allow Drools to be used in a containerless or Tomcat like environment without a JTA implementation available.  Although embeddable solutions are available they are often either buggy or complex.  It would be nice to not have to deal with them if possible.
> If the idea is acceptable I'd be willing to put together an initial patch.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 04:33:23 2011
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Thu, 21 Jul 2011 04:33:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1313) <distributable> web
 applications fail to deploy with the default configuration
In-Reply-To: <540578067.59906.1310987543621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1081549203.71685.1311237203711.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615583#comment-12615583 ] 

Remy Maucherat commented on AS7-1313:
-------------------------------------

I agree, if clustering is not there, I think the distributable flag should probably not be doing anything.

> <distributable> web applications fail to deploy with the default configuration
> ------------------------------------------------------------------------------
>
>                 Key: AS7-1313
>                 URL: https://issues.jboss.org/browse/AS7-1313
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>            Reporter: Stuart Douglas
>            Assignee: Remy Maucherat
>
> <distributable> web applications fail with the following:
> "Services with missing/unavailable dependencies" => ["jboss.web.\"magnolia-bundled-webapp-4.4.4.war\" missing [ jboss.infinispan.web.___defaultcache ]"]}}}
> At the very least the user should get a better error message explaining why their deployment failed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 04:41:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 21 Jul 2011 04:41:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1313) <distributable> web
 applications fail to deploy with the default configuration
In-Reply-To: <540578067.59906.1310987543621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1088242458.71710.1311237684007.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615585#comment-12615585 ] 

jaikiran pai commented on AS7-1313:
-----------------------------------

Right. I remember Paul Ferraro had fixed a similar issue in AS6. I think he should be able to handle it in a similar way in AS7.
 

> <distributable> web applications fail to deploy with the default configuration
> ------------------------------------------------------------------------------
>
>                 Key: AS7-1313
>                 URL: https://issues.jboss.org/browse/AS7-1313
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>            Reporter: Stuart Douglas
>            Assignee: Remy Maucherat
>
> <distributable> web applications fail with the following:
> "Services with missing/unavailable dependencies" => ["jboss.web.\"magnolia-bundled-webapp-4.4.4.war\" missing [ jboss.infinispan.web.___defaultcache ]"]}}}
> At the very least the user should get a better error message explaining why their deployment failed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 04:45:24 2011
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Thu, 21 Jul 2011 04:45:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-8786) JBoss unpacks all
 jars from WEB-INF\lib of war file
In-Reply-To: <576153813.40493.1294234097935.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <648312510.71723.1311237924671.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBAS-8786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

SBS JIRA Integration updated JBAS-8786:
---------------------------------------

    Forum Reference: http://community.jboss.org/message/588576#588576, http://community.jboss.org/thread/160718?tstart=0, http://community.jboss.org/message/609402#609402, http://community.jboss.org/message/587631#587631  (was: http://community.jboss.org/thread/160718?tstart=0, http://community.jboss.org/message/588576#588576, http://community.jboss.org/message/587631#587631)


> JBoss unpacks all jars from WEB-INF\lib of war file
> ---------------------------------------------------
>
>                 Key: JBAS-8786
>                 URL: https://issues.jboss.org/browse/JBAS-8786
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployers, Web (Tomcat) service
>    Affects Versions: 6.0.0.Final
>         Environment: Windows XP x32
>            Reporter: Maxym Pendyshchuk
>            Assignee: jaikiran pai
>            Priority: Blocker
>             Fix For: 6.1.0
>
>         Attachments: jarbomb.zip, JBAS-8786.patch, jboss-as-server.jar
>
>
> while starting JBoss AS it unpacks all jar files, which are located in WEB-INF/lib folder of each my war file. It means that in tmp folder mostly I see folder with jar file, and folder with its content. E.g. jackrabbit-server.war contains library asm-3.1.jar, then in tmp folder I see the following folders with files:
> asm-3.1.jar-83dc35ead0d41d41/asm-3.1.jar
> asm-3.1.jar-2a48f1c13ec7f25d/contents/"unpacked asm-3.1.jar"
> actually when I repack jackrabbit-server.war to jackrabbit-server.ear which contains jackrabbit-server.war and moved all its libraries to jackrabbit-server.ear/lib then I still see two folders in tmp:
> asm-3.1.jar-215a36131ebb088e/asm-3.1.jar
> asm-3.1.jar-14695f157664f00/contents/
> but in this case last folder is empty. So it still creates two folders, but does not unpack my library. Also I use exploded deployment so the question is only about jar files, not unpacking ear/war.
> the problem is that it slows down application server booting (when I repack all my war files as ear and moved war libraries to ear/lib folder then I save 2+ minutes at JBoss 6 booting...). If it is done deliberately (so it improves some performance at runtime), then would be nice to have a configuration option, so during development I can save time to boot my local JBoss AS

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 06:32:23 2011
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Thu, 21 Jul 2011 06:32:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1322) Provide service for
 starting/stop a POJO WS endpoint
In-Reply-To: <1951805285.61094.1311016103850.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <546651986.72002.1311244343670.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano resolved AS7-1322.
----------------------------------

    Resolution: Done


> Provide service for starting/stop a POJO WS endpoint
> ----------------------------------------------------
>
>                 Key: AS7-1322
>                 URL: https://issues.jboss.org/browse/AS7-1322
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Web Services
>            Reporter: Alessio Soldano
>            Assignee: Alessio Soldano
>             Fix For: 7.1.0.Alpha1
>
>
> We need a service for programatically publishing a WS endpoint on JBoss AS 7 HTTP server. There's recently been a mild interest from the community for this and the functionality would be of great use to projects like XTS requiring publishing of endpoints as part of their subsystem boot.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 08:37:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 21 Jul 2011 08:37:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1359) Upgrade to Hibernate
	4.0.0.Beta4
Message-ID: <1656580416.72347.1311251843659.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Upgrade to Hibernate 4.0.0.Beta4
--------------------------------

                 Key: AS7-1359
                 URL: https://issues.jboss.org/browse/AS7-1359
             Project: Application Server 7
          Issue Type: Component  Upgrade
          Components: JPA / Hibernate
            Reporter: Scott Marlow
            Assignee: Scott Marlow
             Fix For: 7.0.1.Final


http://in.relation.to/Bloggers/HibernateCore400Beta4Release

We are currently using Hibernate 4.0.0.Beta1, lets sync up with the latest Hibernate build

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 08:41:23 2011
From: jira-events at lists.jboss.org (Abhijit Sarkar (JIRA))
Date: Thu, 21 Jul 2011 08:41:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1360) Incorrect
 soap:address connector port generated in WSDL for JAX-WS service
Message-ID: <1522203522.72363.1311252083923.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Incorrect soap:address connector port generated in WSDL for JAX-WS service
--------------------------------------------------------------------------

                 Key: AS7-1360
                 URL: https://issues.jboss.org/browse/AS7-1360
             Project: Application Server 7
          Issue Type: Bug
          Components: Web Services
    Affects Versions: 7.0.0.Final
         Environment: Ubuntu 11.04, JBoss AS 7.0.0.Final, RESTEasy 2.2.1.GA
            Reporter: Abhijit Sarkar
            Assignee: Alessio Soldano


Default soap:address connector port generated in WSDL even though server is running on a different HTTP port. Please see forum reference for detail.
??
jaikiran pai wrote:
Please open a JIRA for this. The way the connector port is being inferred from the configured connectors, from the JBoss WS code, will not work in AS7.
??

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 08:43:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 21 Jul 2011 08:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1250) Wrap XAResource by
 default for datasources
In-Reply-To: <1087050933.45258.1310389883723.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1185301523.72369.1311252203648.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved AS7-1250.
----------------------------------

      Assignee: Jesper Pedersen  (was: Stefano Maestri)
    Resolution: Done


> Wrap XAResource by default for datasources
> ------------------------------------------
>
>                 Key: AS7-1250
>                 URL: https://issues.jboss.org/browse/AS7-1250
>             Project: Application Server 7
>          Issue Type: Task
>          Components: JCA
>    Affects Versions: 7.0.0.CR1
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 7.1.0.Alpha1
>
>
> For XA datasources if nothing is specified for in regards to wrapping of XAResource the default should be true.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 08:45:23 2011
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Thu, 21 Jul 2011 08:45:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1283) Cookie-Based
	Sessions Broken
In-Reply-To: <125463836.53501.1310646803618.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <591838156.72375.1311252323808.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Remy Maucherat resolved AS7-1283.
---------------------------------

    Resolution: Done


I separated the flag from the strict compliance flag.

> Cookie-Based Sessions Broken
> ----------------------------
>
>                 Key: AS7-1283
>                 URL: https://issues.jboss.org/browse/AS7-1283
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Final
>            Reporter: Benjamin Browning
>            Assignee: Remy Maucherat
>            Priority: Blocker
>             Fix For: 7.0.1.Final
>
>
> See http://community.jboss.org/message/612763 and http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/003120.html.
> Essentially cookie-based sessions are broken in major browsers and curl unless -Dorg.apache.tomcat.util.http.ServerCookie.FWD_SLASH_IS_SEPARATOR=false is passed on boot. It's likely a large percentage of the people that try AS7 Final will run into this issue and have to spend time trying to figure out why sessions aren't working.
> To summarize the above links, what's happening is the cookie's Path value is being enclosed in quotes. Browsers don't expect this and thus when the browser receives a cookie it doesn't send that cookie back on subsequent requests because the browser doesn't think the cookie's Path value matches the user's path.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 08:49:23 2011
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Thu, 21 Jul 2011 08:49:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1360) Incorrect
 soap:address connector port generated in WSDL for JAX-WS service
In-Reply-To: <1522203522.72363.1311252083923.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <211363700.72390.1311252563736.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano updated AS7-1360:
---------------------------------

           Assignee: Jim Ma  (was: Alessio Soldano)
        Environment: Ubuntu 11.04, JBoss AS 7.0.0.Final  (was: Ubuntu 11.04, JBoss AS 7.0.0.Final, RESTEasy 2.2.1.GA)
    Forum Reference: http://community.jboss.org/message/616633#616633  (was: http://community.jboss.org/message/616633#616633)


> Incorrect soap:address connector port generated in WSDL for JAX-WS service
> --------------------------------------------------------------------------
>
>                 Key: AS7-1360
>                 URL: https://issues.jboss.org/browse/AS7-1360
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>         Environment: Ubuntu 11.04, JBoss AS 7.0.0.Final
>            Reporter: Abhijit Sarkar
>            Assignee: Jim Ma
>
> Default soap:address connector port generated in WSDL even though server is running on a different HTTP port. Please see forum reference for detail.
> ??
> jaikiran pai wrote:
> Please open a JIRA for this. The way the connector port is being inferred from the configured connectors, from the JBoss WS code, will not work in AS7.
> ??

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 08:53:23 2011
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Thu, 21 Jul 2011 08:53:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1321) Upgrade to
	JBossWS-CXF 4.0.0.Beta3
In-Reply-To: <92893259.61080.1311015870101.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <116629553.72399.1311252803716.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano updated AS7-1321:
---------------------------------

    Fix Version/s: 7.0.1.Final
                       (was: 7.1.0.Alpha1)


> Upgrade to JBossWS-CXF 4.0.0.Beta3
> ----------------------------------
>
>                 Key: AS7-1321
>                 URL: https://issues.jboss.org/browse/AS7-1321
>             Project: Application Server 7
>          Issue Type: Component  Upgrade
>          Components: Web Services
>            Reporter: Alessio Soldano
>            Assignee: Alessio Soldano
>             Fix For: 7.0.1.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 09:06:24 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 21 Jul 2011 09:06:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-634) Support query
 timeout for check-valid-connection-sql
In-Reply-To: <2133115945.71016.1311217108832.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1889998662.72421.1311253584040.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-634.
-----------------------------------

    Resolution: Rejected


You should use a 'valid-connection-checker' with a 'config-property' with the query timeout.

  <valid-connection-checker class="MyClass">
     <config-property name="MyQueryTimeout">5</config-property>
  </valid-connection-checker>

Please, use the forum to discuss new features in the future

> Support query timeout for check-valid-connection-sql
> ----------------------------------------------------
>
>                 Key: JBJCA-634
>                 URL: https://issues.jboss.org/browse/JBJCA-634
>             Project: IronJacamar
>          Issue Type: Feature Request
>          Components: JDBC
>    Affects Versions: 1.0.0.Final
>            Reporter: Takayoshi Kimura
>            Assignee: Jesper Pedersen
>
> When network hangs and check-valid-connection-sql is executed, it hangs until socket timeout which is normally 5min or longer.
> We can avoid this long timeout if we have ability to set query timeout for check-valid-connection-sql and the underlying JDBC driver supports query timeout.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 09:06:24 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 21 Jul 2011 09:06:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBJCA-634) Support query timeout
 for check-valid-connection-sql
In-Reply-To: <2133115945.71016.1311217108832.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <447568590.72425.1311253584178.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen closed JBJCA-634.
---------------------------------



> Support query timeout for check-valid-connection-sql
> ----------------------------------------------------
>
>                 Key: JBJCA-634
>                 URL: https://issues.jboss.org/browse/JBJCA-634
>             Project: IronJacamar
>          Issue Type: Feature Request
>          Components: JDBC
>    Affects Versions: 1.0.0.Final
>            Reporter: Takayoshi Kimura
>            Assignee: Jesper Pedersen
>
> When network hangs and check-valid-connection-sql is executed, it hangs until socket timeout which is normally 5min or longer.
> We can avoid this long timeout if we have ability to set query timeout for check-valid-connection-sql and the underlying JDBC driver supports query timeout.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 09:12:23 2011
From: jira-events at lists.jboss.org (Aslak Knutsen (JIRA))
Date: Thu, 21 Jul 2011 09:12:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1361) Arquillian AS7
 Container force a dependency on Arquillian Service in manifest.mf
Message-ID: <826629031.72440.1311253943849.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Arquillian AS7 Container force a dependency on Arquillian Service in manifest.mf
--------------------------------------------------------------------------------

                 Key: AS7-1361
                 URL: https://issues.jboss.org/browse/AS7-1361
             Project: Application Server 7
          Issue Type: Bug
          Components: Test Suite
    Affects Versions: 7.0.0.Final
            Reporter: Aslak Knutsen
            Assignee: Andrew Rubinger
             Fix For: 7.0.1.Final


When trying to e.g. use the Servlet Protocol instead of the jmx-as7 protocol you will get the following exception:

["jboss.deployment.unit.\"624b14c4-2bb2-4d44-be9e-1168c4d29164.war\".CONFIGURE_MODULE missing [ jboss.module.information.service.\"deployment.arquillian-service\".main ]


The AS7 container adds a dependency to the Arquillian Service using ApplicationArchiveProcessors which is a general purpose archive processor and it not tied to the Protocol itself. This handling needs to be moved to the DeploymentPackager.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 09:12:24 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Thu, 21 Jul 2011 09:12:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1344) JGroups subsystem
 TimerSchedulerAdapter throws UOE when using timer-executor
Message-ID: <1002985527.72459.1311253944343.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro reassigned AS7-1344:
---------------------------------

    Assignee: Paul Ferraro  (was: Trustin Lee)


> JGroups subsystem TimerSchedulerAdapter throws UOE when using timer-executor
> ----------------------------------------------------------------------------
>
>                 Key: AS7-1344
>                 URL: https://issues.jboss.org/browse/AS7-1344
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.Final
>            Reporter: Michal Linhard
>            Assignee: Paul Ferraro
>             Fix For: 7.0.1.Final, 7.1.0.Alpha1
>
>
> 07:42:39,535 WARNING [org.jgroups.protocols.UDP] (DiagnosticsHandler,default,perf17-37478) Could not retrieve value of attribute (method) getNumTimerTasks: java.lang.reflect.InvocationTargetException
> [JBoss] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_24]
> [JBoss] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_24]
> [JBoss] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_24]
> [JBoss] 	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_24]
> [JBoss] 	at org.jgroups.stack.Protocol.dumpStats(Protocol.java:272) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at org.jgroups.stack.ProtocolStack.dumpStats(ProtocolStack.java:310) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at org.jgroups.JChannel.dumpStats(JChannel.java:687) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at org.jgroups.JChannel$MyProbeHandler.handleProbe(JChannel.java:2099) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at org.jgroups.protocols.TP$DiagnosticsHandler.handleDiagnosticProbe(TP.java:2165) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at org.jgroups.protocols.TP$DiagnosticsHandler.run(TP.java:2137) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
> [JBoss] Caused by: java.lang.UnsupportedOperationException
> [JBoss] 	at org.jboss.as.clustering.jgroups.TimerSchedulerAdapter.getExecutor(TimerSchedulerAdapter.java:168) [jboss-as-clustering-jgroups-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> [JBoss] 	at org.jboss.as.clustering.jgroups.TimerSchedulerAdapter.size(TimerSchedulerAdapter.java:153) [jboss-as-clustering-jgroups-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> [JBoss] 	at org.jgroups.protocols.TP.getNumTimerTasks(TP.java:714) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	... 11 more
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 09:12:24 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Thu, 21 Jul 2011 09:12:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1344) JGroups subsystem
 TimerSchedulerAdapter throws UOE when using timer-executor
Message-ID: <433912114.72474.1311253944735.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro resolved AS7-1344.
-------------------------------

    Fix Version/s: 7.0.1.Final
                   7.1.0.Alpha1
       Resolution: Done


> JGroups subsystem TimerSchedulerAdapter throws UOE when using timer-executor
> ----------------------------------------------------------------------------
>
>                 Key: AS7-1344
>                 URL: https://issues.jboss.org/browse/AS7-1344
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.Final
>            Reporter: Michal Linhard
>            Assignee: Paul Ferraro
>             Fix For: 7.0.1.Final, 7.1.0.Alpha1
>
>
> 07:42:39,535 WARNING [org.jgroups.protocols.UDP] (DiagnosticsHandler,default,perf17-37478) Could not retrieve value of attribute (method) getNumTimerTasks: java.lang.reflect.InvocationTargetException
> [JBoss] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_24]
> [JBoss] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_24]
> [JBoss] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_24]
> [JBoss] 	at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_24]
> [JBoss] 	at org.jgroups.stack.Protocol.dumpStats(Protocol.java:272) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at org.jgroups.stack.ProtocolStack.dumpStats(ProtocolStack.java:310) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at org.jgroups.JChannel.dumpStats(JChannel.java:687) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at org.jgroups.JChannel$MyProbeHandler.handleProbe(JChannel.java:2099) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at org.jgroups.protocols.TP$DiagnosticsHandler.handleDiagnosticProbe(TP.java:2165) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at org.jgroups.protocols.TP$DiagnosticsHandler.run(TP.java:2137) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
> [JBoss] Caused by: java.lang.UnsupportedOperationException
> [JBoss] 	at org.jboss.as.clustering.jgroups.TimerSchedulerAdapter.getExecutor(TimerSchedulerAdapter.java:168) [jboss-as-clustering-jgroups-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> [JBoss] 	at org.jboss.as.clustering.jgroups.TimerSchedulerAdapter.size(TimerSchedulerAdapter.java:153) [jboss-as-clustering-jgroups-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> [JBoss] 	at org.jgroups.protocols.TP.getNumTimerTasks(TP.java:714) [jgroups-2.12.1.Final.jar:]
> [JBoss] 	... 11 more
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 10:14:24 2011
From: jira-events at lists.jboss.org (Jarod Rose (JIRA))
Date: Thu, 21 Jul 2011 10:14:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-9421) Unable to manually
 create JMS queues in the Admin Console.
Message-ID: <387822167.72598.1311257664430.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Unable to manually create JMS queues in the Admin Console.
----------------------------------------------------------

                 Key: JBAS-9421
                 URL: https://issues.jboss.org/browse/JBAS-9421
             Project: Legacy JBoss Application Server 6 
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMS (HornetQ), Web Console
    Affects Versions: 6.1.0
         Environment: Windows XP SP 3
            Reporter: Jarod Rose
            Assignee: Clebert Suconic


When attempting to create a queue via the JMS Manager in the Admin Console of JBoss 6.1.0-SNAPSHOT (Revision 111808) an error occurs and the queue is not created.  

Steps to reproduce:
1) Start creating a JMS queue off of the default template.
2) Fill in the minimum values to create a queue (Name and JNDI Name)  In my case it was TestQueue and queue/TestQueue
3) Click Save

At the Top of the page this error appears...

Failed to add Resource (see app server log for additional details): Failed to invoke method 'createQueue' on component 'JMSQueueManageMO' with parameters [SimpleMetaType:java.lang.String:TestQueue, SimpleMetaType:java.lang.String:queue/TestQueue, SimpleMetaType:java.lang.String:null, SimpleMetaType:java.lang.String:null, SimpleMetaType:int:-1, SimpleMetaType:int:10485760, SimpleMetaType:int:10, SimpleMetaType:long:0, SimpleMetaType:boolean:false, SimpleMetaType:long:-1, SimpleMetaType:boolean:false, SimpleMetaType:java.lang.String:PAGE, SimpleMetaType:java.lang.String:, SimpleMetaType:java.lang.String:].


And this stack trace appears in the server.log...

2011-07-21 09:38:55,270 INFO  [org.rhq.core.pc.inventory.RuntimeDiscoveryExecutor] (InventoryManager.discovery-1) Running runtime discovery scan rooted at [platform]
2011-07-21 09:38:55,489 INFO  [org.rhq.core.pc.inventory.RuntimeDiscoveryExecutor] (InventoryManager.discovery-1) Scanned [0] servers and found [0] total descendant Resources.
2011-07-21 09:40:03,179 INFO  [org.rhq.core.pc.inventory.CreateResourceRunner] (ResourceFactory.executor-1) Creating resource through report: CreateResourceReport: ResourceType=[ResourceType[id=0, category=Service, name=JMS Queue, plugin=HornetQ]], ResourceKey=[null]
2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) java.lang.reflect.UndeclaredThrowableException: Failed to invoke method 'createQueue' on component 'JMSQueueManageMO' with parameters [SimpleMetaType:java.lang.String:TestQueue, SimpleMetaType:java.lang.String:queue/TestQueue, SimpleMetaType:java.lang.String:null, SimpleMetaType:java.lang.String:null, SimpleMetaType:int:-1, SimpleMetaType:int:10485760, SimpleMetaType:int:10, SimpleMetaType:long:0, SimpleMetaType:boolean:false, SimpleMetaType:long:-1, SimpleMetaType:boolean:false, SimpleMetaType:java.lang.String:PAGE, SimpleMetaType:java.lang.String:, SimpleMetaType:java.lang.String:].

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.profileservice.plugins.management.util.AbstractManagedComponentRuntimeDispatcher.invoke(AbstractManagedComponentRuntimeDispatcher.java:148)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.invoke(DelegatingComponentDispatcherImpl.java:93)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at sun.reflect.GeneratedMethodAccessor446.invoke(Unknown Source)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.lang.reflect.Method.invoke(Method.java:597)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:967)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.remoting.Client.invoke(Client.java:2070)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.remoting.Client.invoke(Client.java:879)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aop.generatedproxies.AOPProxy$0.invoke(AOPProxy$0.java)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.profileservice.management.client.ManagedOperationDelegate.invoke(ManagedOperationDelegate.java:63)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.as.integration.hornetq.jopr.JMSManagerComponent.createQueue(JMSManagerComponent.java:267)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.as.integration.hornetq.jopr.JMSManagerComponent.createResource(JMSManagerComponent.java:149)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.lang.reflect.Method.invoke(Method.java:597)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.lang.Thread.run(Thread.java:619)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) Caused by: org.jboss.joinpoint.spi.JoinpointException: Method not found createQueue[java.lang.String, java.lang.String, java.lang.String, java.lang.String, long, int, int, int, long, boolean, long, boolean, java.lang.String, java.lang.String] for class org.jboss.as.integration.hornetq.management.jms.QueueManageMO

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.joinpoint.plugins.Config.findMethodInfo(Config.java:400)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.joinpoint.plugins.Config.findMethodInfo(Config.java:366)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.joinpoint.plugins.Config.findMethodInfo(Config.java:335)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.joinpoint.plugins.Config.getMethodJoinpoint(Config.java:223)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:299)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:305)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.kernel.plugins.registry.basic.LifecycleAwareKernelBus$1.dispatch(LifecycleAwareKernelBus.java:61)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.kernel.plugins.registry.basic.LifecycleAwareKernelBus$1.dispatch(LifecycleAwareKernelBus.java:58)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:71)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.kernel.plugins.registry.basic.LifecycleAwareKernelBus.invoke(LifecycleAwareKernelBus.java:57)

2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.invoke(KernelBusRuntimeComponentDispatcher.java:85)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.profileservice.plugins.management.util.AbstractManagedComponentRuntimeDispatcher.invoke(AbstractManagedComponentRuntimeDispatcher.java:135)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.invoke(DelegatingComponentDispatcherImpl.java:93)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at sun.reflect.GeneratedMethodAccessor446.invoke(Unknown Source)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.lang.reflect.Method.invoke(Method.java:597)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:967)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.remoting.Client.invoke(Client.java:2070)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.remoting.Client.invoke(Client.java:879)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aop.generatedproxies.AOPProxy$0.invoke(AOPProxy$0.java)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.profileservice.management.client.ManagedOperationDelegate.invoke(ManagedOperationDelegate.java:63)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.as.integration.hornetq.jopr.JMSManagerComponent.createQueue(JMSManagerComponent.java:267)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.as.integration.hornetq.jopr.JMSManagerComponent.createResource(JMSManagerComponent.java:149)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.lang.reflect.Method.invoke(Method.java:597)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.lang.Thread.run(Thread.java:619)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)

2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	... 19 more

2011-07-21 09:40:03,194 INFO  [org.rhq.core.pc.inventory.CreateResourceRunner] (ResourceFactory.executor-1) Sending create response to server: CreateResourceResponse[RequestId=1, Status=Failure]


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 11:16:24 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Thu, 21 Jul 2011 11:16:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1362) FULL_XA infinispan
 caches need to properly register with TransactionManager for recovery.
Message-ID: <122489439.72871.1311261384673.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

FULL_XA infinispan caches need to properly register with TransactionManager for recovery.
-----------------------------------------------------------------------------------------

                 Key: AS7-1362
                 URL: https://issues.jboss.org/browse/AS7-1362
             Project: Application Server 7
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 7.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 7.1.0.Beta1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 11:22:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Thu, 21 Jul 2011 11:22:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1363) JGroups subsystem add
 operation executed using "ha" profile of default domain.xml
Message-ID: <203392093.72951.1311261743826.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

JGroups subsystem add operation executed using "ha" profile of default domain.xml
---------------------------------------------------------------------------------

                 Key: AS7-1363
                 URL: https://issues.jboss.org/browse/AS7-1363
             Project: Application Server 7
          Issue Type: Bug
          Components: Clustering
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro


For whatever reason, in domain mode, the JGroupsSubsystemAdd operation is not being run.  Consequently, clustered infinispan caches will not start due to a missing dependency.
Strangely enough, standalone mode works fine.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 11:24:24 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Thu, 21 Jul 2011 11:24:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1363) JGroups subsystem add
 operation not executed using "ha" profile of default domain.xml
In-Reply-To: <203392093.72951.1311261743826.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1248933941.72975.1311261864910.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated AS7-1363:
------------------------------

    Summary: JGroups subsystem add operation not executed using "ha" profile of default domain.xml  (was: JGroups subsystem add operation executed using "ha" profile of default domain.xml)


> JGroups subsystem add operation not executed using "ha" profile of default domain.xml
> -------------------------------------------------------------------------------------
>
>                 Key: AS7-1363
>                 URL: https://issues.jboss.org/browse/AS7-1363
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> For whatever reason, in domain mode, the JGroupsSubsystemAdd operation is not being run.  Consequently, clustered infinispan caches will not start due to a missing dependency.
> Strangely enough, standalone mode works fine.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 11:40:25 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 21 Jul 2011 11:40:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-9421) Unable to manually
 create JMS queues in the Admin Console.
In-Reply-To: <387822167.72598.1311257664430.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <932137836.73100.1311262825217.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBAS-9421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated JBAS-9421:
-------------------------------

        Fix Version/s: 6.1.0
    Affects Version/s:     (was: 6.1.0)
          Environment: Windows XP SP 3, AS6 trunk (July 21 2011)  (was: Windows XP SP 3)


> Unable to manually create JMS queues in the Admin Console.
> ----------------------------------------------------------
>
>                 Key: JBAS-9421
>                 URL: https://issues.jboss.org/browse/JBAS-9421
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS (HornetQ), Web Console
>         Environment: Windows XP SP 3, AS6 trunk (July 21 2011)
>            Reporter: Jarod Rose
>            Assignee: Clebert Suconic
>              Labels: admin-console, hornetQ, jms
>             Fix For: 6.1.0
>
>
> When attempting to create a queue via the JMS Manager in the Admin Console of JBoss 6.1.0-SNAPSHOT (Revision 111808) an error occurs and the queue is not created.  
> Steps to reproduce:
> 1) Start creating a JMS queue off of the default template.
> 2) Fill in the minimum values to create a queue (Name and JNDI Name)  In my case it was TestQueue and queue/TestQueue
> 3) Click Save
> At the Top of the page this error appears...
> Failed to add Resource (see app server log for additional details): Failed to invoke method 'createQueue' on component 'JMSQueueManageMO' with parameters [SimpleMetaType:java.lang.String:TestQueue, SimpleMetaType:java.lang.String:queue/TestQueue, SimpleMetaType:java.lang.String:null, SimpleMetaType:java.lang.String:null, SimpleMetaType:int:-1, SimpleMetaType:int:10485760, SimpleMetaType:int:10, SimpleMetaType:long:0, SimpleMetaType:boolean:false, SimpleMetaType:long:-1, SimpleMetaType:boolean:false, SimpleMetaType:java.lang.String:PAGE, SimpleMetaType:java.lang.String:, SimpleMetaType:java.lang.String:].
> And this stack trace appears in the server.log...
> 2011-07-21 09:38:55,270 INFO  [org.rhq.core.pc.inventory.RuntimeDiscoveryExecutor] (InventoryManager.discovery-1) Running runtime discovery scan rooted at [platform]
> 2011-07-21 09:38:55,489 INFO  [org.rhq.core.pc.inventory.RuntimeDiscoveryExecutor] (InventoryManager.discovery-1) Scanned [0] servers and found [0] total descendant Resources.
> 2011-07-21 09:40:03,179 INFO  [org.rhq.core.pc.inventory.CreateResourceRunner] (ResourceFactory.executor-1) Creating resource through report: CreateResourceReport: ResourceType=[ResourceType[id=0, category=Service, name=JMS Queue, plugin=HornetQ]], ResourceKey=[null]
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) java.lang.reflect.UndeclaredThrowableException: Failed to invoke method 'createQueue' on component 'JMSQueueManageMO' with parameters [SimpleMetaType:java.lang.String:TestQueue, SimpleMetaType:java.lang.String:queue/TestQueue, SimpleMetaType:java.lang.String:null, SimpleMetaType:java.lang.String:null, SimpleMetaType:int:-1, SimpleMetaType:int:10485760, SimpleMetaType:int:10, SimpleMetaType:long:0, SimpleMetaType:boolean:false, SimpleMetaType:long:-1, SimpleMetaType:boolean:false, SimpleMetaType:java.lang.String:PAGE, SimpleMetaType:java.lang.String:, SimpleMetaType:java.lang.String:].
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.profileservice.plugins.management.util.AbstractManagedComponentRuntimeDispatcher.invoke(AbstractManagedComponentRuntimeDispatcher.java:148)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.invoke(DelegatingComponentDispatcherImpl.java:93)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at sun.reflect.GeneratedMethodAccessor446.invoke(Unknown Source)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.lang.reflect.Method.invoke(Method.java:597)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:967)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.remoting.Client.invoke(Client.java:2070)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.remoting.Client.invoke(Client.java:879)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aop.generatedproxies.AOPProxy$0.invoke(AOPProxy$0.java)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.profileservice.management.client.ManagedOperationDelegate.invoke(ManagedOperationDelegate.java:63)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.as.integration.hornetq.jopr.JMSManagerComponent.createQueue(JMSManagerComponent.java:267)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.as.integration.hornetq.jopr.JMSManagerComponent.createResource(JMSManagerComponent.java:149)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.lang.reflect.Method.invoke(Method.java:597)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.lang.Thread.run(Thread.java:619)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) Caused by: org.jboss.joinpoint.spi.JoinpointException: Method not found createQueue[java.lang.String, java.lang.String, java.lang.String, java.lang.String, long, int, int, int, long, boolean, long, boolean, java.lang.String, java.lang.String] for class org.jboss.as.integration.hornetq.management.jms.QueueManageMO
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.joinpoint.plugins.Config.findMethodInfo(Config.java:400)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.joinpoint.plugins.Config.findMethodInfo(Config.java:366)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.joinpoint.plugins.Config.findMethodInfo(Config.java:335)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.joinpoint.plugins.Config.getMethodJoinpoint(Config.java:223)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:299)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:305)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.kernel.plugins.registry.basic.LifecycleAwareKernelBus$1.dispatch(LifecycleAwareKernelBus.java:61)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.kernel.plugins.registry.basic.LifecycleAwareKernelBus$1.dispatch(LifecycleAwareKernelBus.java:58)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:71)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.kernel.plugins.registry.basic.LifecycleAwareKernelBus.invoke(LifecycleAwareKernelBus.java:57)
> 2011-07-21 09:40:03,179 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.invoke(KernelBusRuntimeComponentDispatcher.java:85)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.profileservice.plugins.management.util.AbstractManagedComponentRuntimeDispatcher.invoke(AbstractManagedComponentRuntimeDispatcher.java:135)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.invoke(DelegatingComponentDispatcherImpl.java:93)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at sun.reflect.GeneratedMethodAccessor446.invoke(Unknown Source)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.lang.reflect.Method.invoke(Method.java:597)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:967)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.remoting.Client.invoke(Client.java:2070)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.remoting.Client.invoke(Client.java:879)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aop.generatedproxies.AOPProxy$0.invoke(AOPProxy$0.java)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.profileservice.management.client.ManagedOperationDelegate.invoke(ManagedOperationDelegate.java:63)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.as.integration.hornetq.jopr.JMSManagerComponent.createQueue(JMSManagerComponent.java:267)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.as.integration.hornetq.jopr.JMSManagerComponent.createResource(JMSManagerComponent.java:149)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.lang.reflect.Method.invoke(Method.java:597)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at java.lang.Thread.run(Thread.java:619)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
> 2011-07-21 09:40:03,194 ERROR [STDERR] (ResourceContainer.invoker.nonDaemon-2) 	... 19 more
> 2011-07-21 09:40:03,194 INFO  [org.rhq.core.pc.inventory.CreateResourceRunner] (ResourceFactory.executor-1) Sending create response to server: CreateResourceResponse[RequestId=1, Status=Failure]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 13:55:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Thu, 21 Jul 2011 13:55:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1364) Upgrade Infinispan to
	5.0.0.CR8
Message-ID: <1578003038.73331.1311270923689.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Upgrade Infinispan to 5.0.0.CR8
-------------------------------

                 Key: AS7-1364
                 URL: https://issues.jboss.org/browse/AS7-1364
             Project: Application Server 7
          Issue Type: Component  Upgrade
          Components: Clustering
    Affects Versions: 7.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 7.0.1.Final, 7.1.0.Alpha1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 14:36:24 2011
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 21 Jul 2011 14:36:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-361) Test server respawn
	logic
In-Reply-To: <355340618.11019.1302165633187.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <206057852.73407.1311273384303.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan resolved AS7-361.
----------------------------

    Fix Version/s: 7.0.1.Final
                       (was: 7.1.0.Alpha1)
       Resolution: Done


> Test server respawn logic
> -------------------------
>
>                 Key: AS7-361
>                 URL: https://issues.jboss.org/browse/AS7-361
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 7.0.1.Final
>
>
> See the comments in AS7-335 which contains a currently disabled test

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 14:38:23 2011
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 21 Jul 2011 14:38:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-826) Fix or remove @Ignore
 in RespawnTestCase
In-Reply-To: <68314947.7050.1305666001665.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1098303382.73412.1311273503715.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan resolved AS7-826.
----------------------------

    Fix Version/s: 7.0.1.Final
       Resolution: Done


> Fix or remove @Ignore in RespawnTestCase
> ----------------------------------------
>
>                 Key: AS7-826
>                 URL: https://issues.jboss.org/browse/AS7-826
>             Project: Application Server 7
>          Issue Type: Sub-task
>            Reporter: Thomas Diesler
>            Assignee: Kabir Khan
>             Fix For: 7.0.1.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 15:39:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Thu, 21 Jul 2011 15:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1365) Add configurable
 jvm-route to web subsystem to support mod_jk and mod_proxy.
Message-ID: <879296760.73495.1311277163672.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Add configurable jvm-route to web subsystem to support mod_jk and mod_proxy.
----------------------------------------------------------------------------

                 Key: AS7-1365
                 URL: https://issues.jboss.org/browse/AS7-1365
             Project: Application Server 7
          Issue Type: Feature Request
          Components: Web
    Affects Versions: 7.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Remy Maucherat




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 15:46:41 2011
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 21 Jul 2011 15:46:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-621) Ports in use message
	better
In-Reply-To: <713656510.6204.1302042093273.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1760726842.73503.1311277601581.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed AS7-621.
--------------------------

      Assignee: Daniel Bevenius
    Resolution: Done


> Ports in use message better
> ---------------------------
>
>                 Key: AS7-621
>                 URL: https://issues.jboss.org/browse/AS7-621
>             Project: Application Server 7
>          Issue Type: Feature Request
>    Affects Versions: 7.0.0.Beta2
>            Reporter: Jim Tyrrell
>            Assignee: Daniel Bevenius
>
> When starting up two instances of JBoss AS 7 beta 2, I get the following error message that is not descriptive enough.  This error should output the IP address and the port number that was not available.
> [Host Controller] 16:13:50,135 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC00001: Failed to start service jboss.host.controller.management.communication: org.jboss.msc.service.StartException in service jboss.host.controller.management.communication: Failed to start server socket
> [Host Controller] 	at org.jboss.as.host.controller.mgmt.ManagementCommunicationService.start(ManagementCommunicationService.java:94)
> [Host Controller] 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1344)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
> [Host Controller] 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_24]
> [Host Controller] Caused by: java.net.BindException: Address already in use
> [Host Controller] 	at java.net.PlainSocketImpl.socketBind(Native Method) [:1.6.0_24]
> [Host Controller] 	at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383) [:1.6.0_24]
> [Host Controller] 	at java.net.ServerSocket.bind(ServerSocket.java:328) [:1.6.0_24]
> [Host Controller] 	at org.jboss.as.protocol.ProtocolServer.start(ProtocolServer.java:118)
> [Host Controller] 	at org.jboss.as.host.controller.mgmt.ManagementCommunicationService.start(ManagementCommunicationService.java:92)
> [Host Controller] 	... 4 more
> [Host Controller] 
> [Host Controller] 16:13:50,138 ERROR [org.jboss.as.host.controller] (MSC service thread 1-3) Service [service jboss.host.controller.management.communication] failed.: org.jboss.msc.service.StartException in service jboss.host.controller.management.communication: Failed to start server socket
> [Host Controller] 	at org.jboss.as.host.controller.mgmt.ManagementCommunicationService.start(ManagementCommunicationService.java:94)
> [Host Controller] 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1344)
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
> [Host Controller] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
> [Host Controller] 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_24]
> [Host Controller] Caused by: java.net.BindException: Address already in use
> [Host Controller] 	at java.net.PlainSocketImpl.socketBind(Native Method) [:1.6.0_24]
> [Host Controller] 	at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383) [:1.6.0_24]
> [Host Controller] 	at java.net.ServerSocket.bind(ServerSocket.java:328) [:1.6.0_24]
> [Host Controller] 	at org.jboss.as.protocol.ProtocolServer.start(ProtocolServer.java:118)
> [Host Controller] 	at org.jboss.as.host.controller.mgmt.ManagementCommunicationService.start(ManagementCommunicationService.java:92)
> [Host Controller] 	... 4 more
> [Host Controller] 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 15:50:23 2011
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Thu, 21 Jul 2011 15:50:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1365) Add configurable
 jvm-route to web subsystem to support mod_jk and mod_proxy.
In-Reply-To: <879296760.73495.1311277163672.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1508865899.73508.1311277823670.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Remy Maucherat resolved AS7-1365.
---------------------------------

    Resolution: Rejected


I like the automagic configuration. For test/hack/whatever, the "jvmRoute" system property can be set.

> Add configurable jvm-route to web subsystem to support mod_jk and mod_proxy.
> ----------------------------------------------------------------------------
>
>                 Key: AS7-1365
>                 URL: https://issues.jboss.org/browse/AS7-1365
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Web
>    Affects Versions: 7.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Remy Maucherat
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 15:56:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 21 Jul 2011 15:56:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1366) HostController only
 pushes ops to servers whose config has auto-start=true
Message-ID: <892245872.73515.1311278183692.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

HostController only pushes ops to servers whose config has auto-start=true
--------------------------------------------------------------------------

                 Key: AS7-1366
                 URL: https://issues.jboss.org/browse/AS7-1366
             Project: Application Server 7
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 7.0.0.Final
            Reporter: Brian Stansberry
             Fix For: 7.0.1.Final


The auto-start attribute on a server-config controls whether the HC should start it at boot, not whether it is currently started. So it shouldn't be used as the driver for whether a server needs to have a change applied to its runtime.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 16:55:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 21 Jul 2011 16:55:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1363) JGroups subsystem
 add operation not executed using "ha" profile of default domain.xml
In-Reply-To: <203392093.72951.1311261743826.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1294784066.73637.1311281723800.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned AS7-1363:
-------------------------------------

    Assignee: Brian Stansberry  (was: Paul Ferraro)


> JGroups subsystem add operation not executed using "ha" profile of default domain.xml
> -------------------------------------------------------------------------------------
>
>                 Key: AS7-1363
>                 URL: https://issues.jboss.org/browse/AS7-1363
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Brian Stansberry
>
> For whatever reason, in domain mode, the JGroupsSubsystemAdd operation is not being run.  Consequently, clustered infinispan caches will not start due to a missing dependency.
> Strangely enough, standalone mode works fine.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 17:03:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 21 Jul 2011 17:03:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1363) JGroups subsystem
 add operation not executed using "ha" profile of default domain.xml
In-Reply-To: <203392093.72951.1311261743826.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1015561308.73661.1311282203632.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved AS7-1363.
-----------------------------------

    Fix Version/s: 7.0.1.Final
       Resolution: Done


http://github.com/jbossas/jboss-as/compare/c7a0c16...06426a3

Note the jacorb subsystem had the same issue.

> JGroups subsystem add operation not executed using "ha" profile of default domain.xml
> -------------------------------------------------------------------------------------
>
>                 Key: AS7-1363
>                 URL: https://issues.jboss.org/browse/AS7-1363
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>            Reporter: Paul Ferraro
>            Assignee: Brian Stansberry
>             Fix For: 7.0.1.Final
>
>
> For whatever reason, in domain mode, the JGroupsSubsystemAdd operation is not being run.  Consequently, clustered infinispan caches will not start due to a missing dependency.
> Strangely enough, standalone mode works fine.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 19:41:24 2011
From: jira-events at lists.jboss.org (Chris Lowe (JIRA))
Date: Thu, 21 Jul 2011 19:41:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1358) UserTransaction not
 available to non-EE threads
In-Reply-To: <15939283.70650.1311197423915.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <868263798.75039.1311291684112.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris Lowe updated AS7-1358:
----------------------------

    Git Pull Request: https://github.com/jbossas/jboss-as/pull/91
     Forum Reference: http://community.jboss.org/message/616375#616375  (was: http://community.jboss.org/message/616375#616375)


Updated with git pull request

> UserTransaction not available to non-EE threads
> -----------------------------------------------
>
>                 Key: AS7-1358
>                 URL: https://issues.jboss.org/browse/AS7-1358
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Transactions
>    Affects Versions: 7.0.0.Final
>            Reporter: Chris Lowe
>            Assignee: Jonathan Halliday
>
> JBoss Seam offers Asynchronous behaviour for non-EJB environments using a Quartz dispatcher. Asynchronous behaviour may also make use of Seam's @Transactional marker to demarcate tx boundaries.
> Since testing one of our applications in AS7 I noticed Seam "could not discover transaction status" error messages reported as our application ran async sections of code.
> Examining the Seam code, I could see that Seam would make two attempts to access a JNDI UserTransaction resource:
> 1 - context.lookup("java:comp/UserTransaction");
> If an NameNotFoundException is thrown, then attempt:
> 2 - context.lookup("UserTransaction");
> Under AS6 and below, the latter attempt would succeed.  Under AS7 attempts are currently failing.
> While looking into this issue I came across the following developer discussion which suggests that it might be possible to add a "java:/jboss/UserTransaction" resource:
> http://lists.jboss.org/pipermail/jboss-as7-dev/2011-June/002298.html
> Further discussion on my AS7 user forum thread lead to the suggestion that I myself might add this behaviour.
> I have followed the implementation hints and light testing has been successful (with appropriate mods to Seam to use the new resource name).  I aim to perform some more thorough testing on this shortly and submit a patch against this issue.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 20:57:23 2011
From: jira-events at lists.jboss.org (Misty Stanley-Jones (JIRA))
Date: Thu, 21 Jul 2011 20:57:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1365) Add configurable
 jvm-route to web subsystem to support mod_jk and mod_proxy.
In-Reply-To: <879296760.73495.1311277163672.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1019333329.75049.1311296243753.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615797#comment-12615797 ] 

Misty Stanley-Jones commented on AS7-1365:
------------------------------------------

If this one is rejected, what still needs to happen for mod_proxy and mod_jk support?

> Add configurable jvm-route to web subsystem to support mod_jk and mod_proxy.
> ----------------------------------------------------------------------------
>
>                 Key: AS7-1365
>                 URL: https://issues.jboss.org/browse/AS7-1365
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Web
>    Affects Versions: 7.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Remy Maucherat
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 20:57:23 2011
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Thu, 21 Jul 2011 20:57:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1339) Expose RA config
 properties in DMR
In-Reply-To: <639400179.62523.1311076583633.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1045871698.75053.1311296243887.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang resolved AS7-1339.
-----------------------------

    Resolution: Done


> Expose RA config properties in DMR
> ----------------------------------
>
>                 Key: AS7-1339
>                 URL: https://issues.jboss.org/browse/AS7-1339
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jeff Zhang
>            Priority: Critical
>             Fix For: 7.1.0.Beta1
>
>
> {noformat}
> The config attributes are not exposed:
> <subsystem xmlns="urn:jboss:domain:resource-adapters:1.0">
> 	[...]         
> 	
>          <config-property name="host">talk.google.com</config-property>
>          <config-property name="port">5222</config-property>
>   
> 	[...]
>    </resource-adapters>
> [standalone at localhost:9999 /] /subsystem=resource-adapters/resource-adapter=xmpp-ra.rar:read-resource
> {
>     "outcome" => "success",
>     "result" => {
>         "archive" => "xmpp-ra.rar",
>         "background-validation" => undefined,
>         "background-validation-minutes" => undefined,
>         "blocking-timeout-wait-millis" => undefined,
>         "connection-definitions" => [{
>             "class-name" => "com/ramphastos/xmpp/jca/XmppManagedConnectionFactory",
>             "jndi-name" => "java:/eis/ra-xmpp",
>             "pool-name" => "XmppFactoryPool",
>             "enabled" => true,
>             "use-java-context" => true,
>             "use-ccm" => true,
>             "max-pool-size" => 100,
>             "min-pool-size" => 10,
>             "pool-prefill" => false,
>             "pool-use-strict-min" => false,
>             "flush-strategy" => "FAILING_CONNECTION_ONLY",
>             "security-application" => true
>         }],
>         "idle-timeout-minutes" => undefined,
>         "max-pool-size" => undefined,
>         "min-pool-size" => undefined,
>         "pool-prefill" => undefined,
>         "pool-use-strict-min" => undefined,
>         "transaction-support" => "NoTransaction",
>         "use-fast-fail" => undefined
>     }
> }
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 20:57:23 2011
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Thu, 21 Jul 2011 20:57:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1203) test for missing
 xa-datasource properties
In-Reply-To: <1239715458.37294.1309955003698.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1680677901.75055.1311296243949.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang resolved AS7-1203.
-----------------------------

    Fix Version/s: 7.0.1.Final
                       (was: 7.1.0.CR1)
       Resolution: Done


> test for missing xa-datasource properties
> -----------------------------------------
>
>                 Key: AS7-1203
>                 URL: https://issues.jboss.org/browse/AS7-1203
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: Test Suite
>            Reporter: Stefano Maestri
>            Assignee: Jeff Zhang
>             Fix For: 7.0.1.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 20:59:23 2011
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Thu, 21 Jul 2011 20:59:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1212)
 :read-operation-description(name=add) shows pool-name as optional,
 but deploy without pool-name fail
In-Reply-To: <2010325607.37641.1309966343681.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1486946133.75061.1311296363966.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang resolved AS7-1212.
-----------------------------

    Fix Version/s: 7.0.1.Final
       Resolution: Done


> :read-operation-description(name=add) shows pool-name as optional, but deploy without pool-name fail
> ----------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1212
>                 URL: https://issues.jboss.org/browse/AS7-1212
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management, JCA
>    Affects Versions: 7.0.0.CR1
>            Reporter: Heiko Rupp
>            Assignee: Jeff Zhang
>             Fix For: 7.0.1.Final
>
>
> [domain at localhost:9999 subsystem=datasources] ./data-source=java\:jboss\/datasources\/ExampleDS:read-operation-description(name=add)
> {
>     "outcome" => "success",
>     "result" => {
>         "operation-name" => "add",
>         "description" => "Adds a new data-source",
>         "request-properties" => {
> ....
>        "pool-name" => {
>                 "description" => "Specifies the pool name for the datasource used for management",
>                 "type" => STRING,
>                 "required" => false
>             },
> So the pool-name is optional, but when I deploy a data source without pool name, deployment fails: 
> [Server:server-one] 17:26:49,124 ERROR [stderr] (pool-1-thread-42) org.jboss.jca.common.api.validator.ValidateException: IJ010068: Missing required attribute pool-name in org.jboss.jca.common.metadata.ds.DataSourceImpl

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 22:09:23 2011
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Thu, 21 Jul 2011 22:09:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1367)
 size-rotating-file-handler rotate-size doens't properly handle add/update
 with management API
Message-ID: <247240553.75098.1311300563630.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

size-rotating-file-handler rotate-size doens't properly handle add/update with management API
---------------------------------------------------------------------------------------------

                 Key: AS7-1367
                 URL: https://issues.jboss.org/browse/AS7-1367
             Project: Application Server 7
          Issue Type: Bug
          Components: Logging
    Affects Versions: 7.0.0.Final
            Reporter: Stan Silvert
            Assignee: Stan Silvert
             Fix For: 7.1.0.Alpha1


>From the management API, rotate-size doesn't handle the one-character suffixes for (b)yte, (k)ilobyte, (m)egabyte, etc.  

So for instance, if you say:
/subsystem=logging/size-rotating-file-handler=SIZE:update-properties(rotate-size=5m)

You will get an error because it will try to convert that to a long.  If you enter a valid long without a suffix, then the value will be corrupted when the server is restarted.

The solution is to keep this attribute as a String in the management model and only parse out the suffix when you need to convert to a long for the runtime.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 23:13:23 2011
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Thu, 21 Jul 2011 23:13:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1346) Adding RA fails
In-Reply-To: <1237903510.68346.1311153445173.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1303231801.75110.1311304403668.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615803#comment-12615803 ] 

Jeff Zhang commented on AS7-1346:
---------------------------------

hi Heiko,

I checked this. Since RA subsystem use archive name as node name, like resource-adapter=xmpp-ra.rar
The code is L438 in ResourceAdaptersExtension.java
raAddress.add(RESOURCEADAPTER, ra.getArchive());

That to add resource-adapter by cli should be:
./resource-adapter=xmpp-ra.rar:add(archive="xmpp-ra.rar",transacation-support="Notransaction",connection-definitions=[{"class-name" => "com.ramphastos.xmpp.XmppConnectionFactory","jndi-name" => "eis/xmpp2","pool-name"=>"xmpp_Pool"}])

I tested on latest AS7, and restart, everything looks correct.

I will close this. If you find something wrong, please reopen it.
Thanks!


> Adding RA fails
> ---------------
>
>                 Key: AS7-1346
>                 URL: https://issues.jboss.org/browse/AS7-1346
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.Alpha1
>
>
> Adding a new RA fails:
> {noformat}
> Request:
> [INFO] {
> [INFO]     "operation" => "add",
> [INFO]     "address" => [
> [INFO]         ("subsystem" => "resource-adapters"),
> [INFO]         ("resource-adapter" => "xmpp")
> [INFO]     ],
> [INFO]     "archive" => "xmpp-ra.rar",
> [INFO]     "transaction-support" => "NoTransaction",
> [INFO]     "connection-definitions" => [{
> [INFO]         "class-name" => "com.ramphastos.xmpp.XmppConnectionFactory",
> [INFO]         "jndi-name" => "eis/xmpp2",
> [INFO]         "pool-name" => "xmpp_Pool"
> [INFO]     }]
> [INFO] }
> Server Log:
> 11:11:43,826 ERROR [org.jboss.as.controller] (pool-2-thread-2) Operation ("remove") failed - address: ([
>     ("subsystem" => "resource-adapters"),
>     ("resource-adapter" => "xmpp")
> ]): java.util.NoSuchElementException: "resource-adapter" => "xmpp"
> 	at org.jboss.as.controller.registry.BasicResource.requireChild(BasicResource.java:95)
> 	at org.jboss.as.controller.OperationContextImpl.readModel(OperationContextImpl.java:697)
> 	at org.jboss.as.connector.subsystems.resourceadapters.RaRemove.execute(RaRemove.java:51)
> 	at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
> 	at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
> 	at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 23:15:24 2011
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Thu, 21 Jul 2011 23:15:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-1346) Adding RA fails
In-Reply-To: <1237903510.68346.1311153445173.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1867548923.75116.1311304524028.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang closed AS7-1346.
---------------------------

    Resolution: Won't Fix


> Adding RA fails
> ---------------
>
>                 Key: AS7-1346
>                 URL: https://issues.jboss.org/browse/AS7-1346
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.Alpha1
>
>
> Adding a new RA fails:
> {noformat}
> Request:
> [INFO] {
> [INFO]     "operation" => "add",
> [INFO]     "address" => [
> [INFO]         ("subsystem" => "resource-adapters"),
> [INFO]         ("resource-adapter" => "xmpp")
> [INFO]     ],
> [INFO]     "archive" => "xmpp-ra.rar",
> [INFO]     "transaction-support" => "NoTransaction",
> [INFO]     "connection-definitions" => [{
> [INFO]         "class-name" => "com.ramphastos.xmpp.XmppConnectionFactory",
> [INFO]         "jndi-name" => "eis/xmpp2",
> [INFO]         "pool-name" => "xmpp_Pool"
> [INFO]     }]
> [INFO] }
> Server Log:
> 11:11:43,826 ERROR [org.jboss.as.controller] (pool-2-thread-2) Operation ("remove") failed - address: ([
>     ("subsystem" => "resource-adapters"),
>     ("resource-adapter" => "xmpp")
> ]): java.util.NoSuchElementException: "resource-adapter" => "xmpp"
> 	at org.jboss.as.controller.registry.BasicResource.requireChild(BasicResource.java:95)
> 	at org.jboss.as.controller.OperationContextImpl.readModel(OperationContextImpl.java:697)
> 	at org.jboss.as.connector.subsystems.resourceadapters.RaRemove.execute(RaRemove.java:51)
> 	at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
> 	at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
> 	at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 21 23:25:24 2011
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Thu, 21 Jul 2011 23:25:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1347) RA property
 representation is incompatible with DMR model
In-Reply-To: <1232797559.68368.1311155723631.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <966312273.75124.1311305124218.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615805#comment-12615805 ] 

Jeff Zhang commented on AS7-1347:
---------------------------------

hi Heiko,
Could you give me more hint about this?
Thanks

> RA property representation is incompatible with DMR model
> ---------------------------------------------------------
>
>                 Key: AS7-1347
>                 URL: https://issues.jboss.org/browse/AS7-1347
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jeff Zhang
>            Priority: Critical
>             Fix For: 7.1.0.Alpha1
>
>
> They way the resource adapter properties are currently represented they cannot be described in a DMR operation and thus not be added/created. Take a look at xa-data-source properties to see how it should be done.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 02:49:23 2011
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Fri, 22 Jul 2011 02:49:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3150) NPE in
 ObjectTypeConfigurationRegistry when accumulate returns null (and "quick
 hack for 5.2")
Message-ID: <275785913.75467.1311317363611.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

NPE in ObjectTypeConfigurationRegistry when accumulate returns null (and "quick hack for 5.2")
----------------------------------------------------------------------------------------------

                 Key: JBRULES-3150
                 URL: https://issues.jboss.org/browse/JBRULES-3150
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core  (expert)
    Affects Versions: 5.2.0.Final
            Reporter: Wolfgang Laun
            Assignee: Mark Proctor
             Fix For: 5.2.1.Final


rule foo # the problem is usually better "hidden"
when
Object() from accumulate( Object(),
  init( Object res = null; )
  action( res = null; )
  result( res ) )
then
end

causes the exception as shown below, or similar.
A runtime diagnostic should tell the user (at least) that
an accumulate result is null.

ALSO, PLEASE NOTE THIS COMMENT in AccumulateNode.java:642!
// this is a quick hack for the 5.2 release


Exception in thread "main" java.lang.NullPointerException
	at org.drools.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:58)
	at org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:646)
	at org.drools.reteoo.AccumulateNode.assertLeftTuple(AccumulateNode.java:183)
	at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:197)
	at org.drools.reteoo.SingleLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:146)
	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154)
	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:204)
	at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:191)
	at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:332)
	at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:293)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:905)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:864)
	at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:255)
	at match.Main.makeFacts(Main.java:120)
	at match.Main.execute(Main.java:98)
	at match.Main.main(Main.java:126)


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 03:11:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Fri, 22 Jul 2011 03:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1346) Adding RA fails
In-Reply-To: <1237903510.68346.1311153445173.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <727114824.75487.1311318683705.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615814#comment-12615814 ] 

Heiko Braun commented on AS7-1346:
----------------------------------

In that case the name attribute should be removed

> Adding RA fails
> ---------------
>
>                 Key: AS7-1346
>                 URL: https://issues.jboss.org/browse/AS7-1346
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.Alpha1
>
>
> Adding a new RA fails:
> {noformat}
> Request:
> [INFO] {
> [INFO]     "operation" => "add",
> [INFO]     "address" => [
> [INFO]         ("subsystem" => "resource-adapters"),
> [INFO]         ("resource-adapter" => "xmpp")
> [INFO]     ],
> [INFO]     "archive" => "xmpp-ra.rar",
> [INFO]     "transaction-support" => "NoTransaction",
> [INFO]     "connection-definitions" => [{
> [INFO]         "class-name" => "com.ramphastos.xmpp.XmppConnectionFactory",
> [INFO]         "jndi-name" => "eis/xmpp2",
> [INFO]         "pool-name" => "xmpp_Pool"
> [INFO]     }]
> [INFO] }
> Server Log:
> 11:11:43,826 ERROR [org.jboss.as.controller] (pool-2-thread-2) Operation ("remove") failed - address: ([
>     ("subsystem" => "resource-adapters"),
>     ("resource-adapter" => "xmpp")
> ]): java.util.NoSuchElementException: "resource-adapter" => "xmpp"
> 	at org.jboss.as.controller.registry.BasicResource.requireChild(BasicResource.java:95)
> 	at org.jboss.as.controller.OperationContextImpl.readModel(OperationContextImpl.java:697)
> 	at org.jboss.as.connector.subsystems.resourceadapters.RaRemove.execute(RaRemove.java:51)
> 	at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
> 	at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
> 	at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 03:19:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Fri, 22 Jul 2011 03:19:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1368) Provide advanced
 datasource configuration options through the web interface
Message-ID: <1729859759.75491.1311319163738.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Provide advanced datasource configuration options through the web interface
---------------------------------------------------------------------------

                 Key: AS7-1368
                 URL: https://issues.jboss.org/browse/AS7-1368
             Project: Application Server 7
          Issue Type: Feature Request
          Components: Console
            Reporter: Heiko Braun
            Assignee: Heiko Braun
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 03:33:23 2011
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Fri, 22 Jul 2011 03:33:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1365) Add configurable
 jvm-route to web subsystem to support mod_jk and mod_proxy.
In-Reply-To: <879296760.73495.1311277163672.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <915424186.75509.1311320003809.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615817#comment-12615817 ] 

Remy Maucherat commented on AS7-1365:
-------------------------------------

The jvm route is configurable with the "jvmRoute" system property.

> Add configurable jvm-route to web subsystem to support mod_jk and mod_proxy.
> ----------------------------------------------------------------------------
>
>                 Key: AS7-1365
>                 URL: https://issues.jboss.org/browse/AS7-1365
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Web
>    Affects Versions: 7.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Remy Maucherat
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 03:40:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Fri, 22 Jul 2011 03:40:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-1347) RA property
 representation is incompatible with DMR model
In-Reply-To: <1232797559.68368.1311155723631.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2017837138.75519.1311320423674.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun closed AS7-1347.
----------------------------

         Assignee: Heiko Braun  (was: Jeff Zhang)
    Fix Version/s:     (was: 7.1.0.Alpha1)
       Resolution: Won't Fix


> RA property representation is incompatible with DMR model
> ---------------------------------------------------------
>
>                 Key: AS7-1347
>                 URL: https://issues.jboss.org/browse/AS7-1347
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>            Priority: Critical
>
> They way the resource adapter properties are currently represented they cannot be described in a DMR operation and thus not be added/created. Take a look at xa-data-source properties to see how it should be done.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 05:34:23 2011
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Fri, 22 Jul 2011 05:34:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-203) Segfault if not
	enought threads
In-Reply-To: <1974327219.10775.1308677603798.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <752017082.75672.1311327263696.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615837#comment-12615837 ] 

Remy Maucherat commented on JBWEB-203:
--------------------------------------

This would possibly indicate a (mysterious) issue with the internal thread pool ? Note that the connectors are not designed to operate with a single thread.

> Segfault if not enought threads
> -------------------------------
>
>                 Key: JBWEB-203
>                 URL: https://issues.jboss.org/browse/JBWEB-203
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>         Environment: JBoss 6, Debian 6.0.1, JBoss native APR connector 2.0.9
>            Reporter: Dmitry Murashenkov
>            Assignee: Remy Maucherat
>         Attachments: hs_err_pid13822.log
>
>
> If number of requests to server is larger than the max number of worker threads - segmentation fault is raised very often. This bug was originally reported against tomcat native library, but is present in jboss native connector too: 
> https://issues.apache.org/bugzilla/show_bug.cgi?id=49595
> TC:
> 1. Setup ARP. In case of debian we tried: libs (libtcnative and its dependencies) that are available in debian repository, jboss native 2.0.9 linux binary package, tried compiling 2.0.9 package from source. In all cases we validated that neccessary lib is used via ldd and pmap.
> 2. Setup few worker threads in http connector:
> <Connector ... maxThreads="1"/>
> 3. Start sending http requests to server in parallel. In our case load client is sending requests in 40 parallel threads. So it tries to open new connection and send request to maintain parallel sending rate, often get Connection reset by peer exception and tries again. After 15-25 seconds of such load jboss crashes with segmentation fault. In our case the bug is reproduced in 100% cases in this period of time.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 05:41:23 2011
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Fri, 22 Jul 2011 05:41:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-160) XNIO Connector
In-Reply-To: <175728225.1263830207972.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <430928082.75688.1311327683755.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBWEB-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Remy Maucherat updated JBWEB-160:
---------------------------------

        Fix Version/s:     (was: JBossWeb-3.0.0.Final)
    Affects Version/s: JBossWeb-7.0.0.GA


> XNIO Connector
> --------------
>
>                 Key: JBWEB-160
>                 URL: https://issues.jboss.org/browse/JBWEB-160
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-7.0.0.GA
>            Reporter: Remy Maucherat
>            Assignee: Remy Maucherat
>
> Experiment with XNIO connector to determine if it makes sense to include one in JBW.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 05:41:24 2011
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Fri, 22 Jul 2011 05:41:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-8297) Weld throws error
 No active contexts for scope type javax.enterprise.context.RequestScoped
Message-ID: <63176323.75692.1311327684172.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBAS-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615838#comment-12615838 ] 

Remy Maucherat commented on JBAS-8297:
--------------------------------------

A web build from the AS 7 branch is not going to be directly compatible.

> Weld throws error No active contexts for scope type javax.enterprise.context.RequestScoped
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-8297
>                 URL: https://issues.jboss.org/browse/JBAS-8297
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>          Components: Weld/CDI
>         Environment: JBoss 6.0.0.M2, Windows XP SP3
>            Reporter: Marcos Antonio
>            Assignee: Remy Maucherat
>             Fix For: 6.1.0
>
>         Attachments: solicitacoes.zip
>
>
> 2010-04-22 09:55:36,484 WARN  [org.apache.catalina.authenticator.FormAuthenticator] (http-127.0.0.1-8080-1) Unexpected error forwarding to login page: javax.servlet.ServletException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 05:51:23 2011
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Fri, 22 Jul 2011 05:51:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-799) Wrong Classloader
 Used When Deserializing Persisted Sessions
In-Reply-To: <468185631.5268.1305634621553.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <505292123.75714.1311328283844.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615839#comment-12615839 ] 

Remy Maucherat commented on AS7-799:
------------------------------------

The code is using a straight ObjectInputStream, which uses some latestUserDefinedLoader() magic trick to get the classloader. Session persistence is now disabled by default, and this could have been caused by the context CL binding which was a bit off (causing a leak issue), so I'll wait to see if it still happens.

> Wrong Classloader Used When Deserializing Persisted Sessions
> ------------------------------------------------------------
>
>                 Key: AS7-799
>                 URL: https://issues.jboss.org/browse/AS7-799
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Beta3
>            Reporter: Benjamin Browning
>            Assignee: Remy Maucherat
>
> The org.jboss.as.web:main module's classloader is being used when deserializing persisted sessions instead of the deployment's classloader. This leads to errors like the one below when any classes are referenced in the session that aren't in the dependency list of org/jboss/as/web/main/module.xml.
> 21:02:50,824 ERROR [org.apache.catalina.session.ManagerBase] (MSC service thread 1-1) ClassNotFoundException while loading persisted sessions: java.lang.ClassNotFoundException: org.jboss.weld.context.conversation.ConversationIdGenerator from [Module "org.jboss.as.web:main" from local module loader @32b0bad7 (roots: /Users/bbrowning/src/torquebox/integration-tests/target/integ-dist/jboss/modules)]: java.lang.ClassNotFoundException: org.jboss.weld.context.conversation.ConversationIdGenerator from [Module "org.jboss.as.web:main" from local module loader @32b0bad7 (roots: /Users/bbrowning/src/torquebox/integration-tests/target/integ-dist/jboss/modules)]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:184) [:1.0.0.Beta17]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:357) [:1.0.0.Beta17]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:329) [:1.0.0.Beta17]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:306) [:1.0.0.Beta17]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:100) [:1.0.0.Beta17]
> at java.lang.Class.forName0(Native Method) [:1.6.0_24]
> at java.lang.Class.forName(Class.java:247) [:1.6.0_24]
> at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:603) [:1.6.0_24]
> at org.apache.catalina.util.CustomObjectInputStream.resolveClass(CustomObjectInputStream.java:78) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1574) [:1.6.0_24]
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495) [:1.6.0_24]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731) [:1.6.0_24]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) [:1.6.0_24]
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) [:1.6.0_24]
> at org.apache.catalina.session.StandardSession.readObject(StandardSession.java:1429) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
> at org.apache.catalina.session.StandardSession.readObjectData(StandardSession.java:934) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
> at org.apache.catalina.session.StandardManager.doLoad(StandardManager.java:395) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
> at org.apache.catalina.session.StandardManager.load(StandardManager.java:322) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
> at org.apache.catalina.session.StandardManager.start(StandardManager.java:633) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
> at org.apache.catalina.core.ContainerBase.setManager(ContainerBase.java:459) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:3776) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
> at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:61) [jboss-as-web-7.0.0.Beta3.jar:7.0.0.Beta3]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675)
> 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]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 05:57:23 2011
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Fri, 22 Jul 2011 05:57:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-201) JBoss Web Native
 causes JVM crash
In-Reply-To: <1610434667.259.1307874923304.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1039934554.75720.1311328643740.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615840#comment-12615840 ] 

Remy Maucherat commented on JBWEB-201:
--------------------------------------

The server is doing nothing when it crashes. So what happens on your (single) connection which causes the problem ?

> JBoss Web Native causes JVM crash
> ---------------------------------
>
>                 Key: JBWEB-201
>                 URL: https://issues.jboss.org/browse/JBWEB-201
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-3.0.0.CR1
>         Environment: RHEL x64. JBoss AS 6.0.0.Final
>            Reporter: Phil Haigh
>            Assignee: Remy Maucherat
>              Labels: jboss, native
>         Attachments: hs_err_pid14823.log
>
>
> Install latest JBoss native (2.0.9) libraries on JBossAS 6.0.0.Final (which uses JBoss Web 3.0.0.CR1), JDK 1.6.0_26  and JVM crashes out soon after application start.
> Snippet from crash report (full file attached):
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x00002aaab5b0f468, pid=14823, tid=1191192896
> #
> # JRE version: 6.0_26-b03
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.1-b02 mixed mode linux-amd64 compressed oops)
> # Problematic frame:
> # C  [libapr-1.so.0+0x1d468]  signed char+0x68
> #
> # If you would like to submit a bug report, please visit:
> #   http://java.sun.com/webapps/bugreport/crash.jsp
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #
> ---------------  T H R E A D  ---------------
> Current thread (0x00002aaac2d09000):  JavaThread "ajp-127.0.0.1-8009-Poller" daemon [_thread_in_native, id=15006, stack(0x0000000046
> f02000,0x0000000047003000)]
> siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000000000008
> Registers:
> RAX=0x0000000000000000, RBX=0x0000000047001ad0, RCX=0x0000000047001a90, RDX=0x00002aaac453f688
> RSP=0x0000000047001a90, RBP=0x00002aaac2d06b38, RSI=0x0000000000000001, RDI=0x0000000000000259
> R8 =0x0000000000000001, R9 =0x00002aaac453f688, R10=0x00002aaaab02eadf, R11=0x00002ba6c4d23170
> R12=0x00002aaac453f688, R13=0x0000000047001a90, R14=0x0000000000000000, R15=0x00002aaac2d09000
> RIP=0x00002aaab5b0f468, EFLAGS=0x0000000000010206, CSGSFS=0x0000000000000033, ERR=0x0000000000000004
>   TRAPNO=0x000000000000000e
> Top of Stack: (sp=0x0000000047001a90)
> 0x0000000047001a90:   c453f68800000001 00002ba600002aaa
> 0x0000000047001aa0:   00002aaac4f365f8 0000000047001ad0
> 0x0000000047001ab0:   0000000000000000 00000007ea4d0e58
> 0x0000000047001ac0:   0000000047001bb8 00002aaab564c147
> 0x0000000047001ad0:   0000000000000000 0000000100000001
> 0x0000000047001ae0:   0000000000000000 00000000514505e8
> 0x0000000047001af0:   00002aaac2d09000 00000007ea4d0e58
> 0x0000000047001b00:   0000000047001b78 00002aaaab02eb0c
> 0x0000000047001b10:   0000000000000001 00000007e002ee78
> 0x0000000047001b20:   0000000000000000 0000000047001bb8
> 0x0000000047001b30:   0000000047001b88 0000000047001b38
> 0x0000000047001b40:   0000000000000000 0000000047001bb8
> 0x0000000047001b50:   00000007ea4d1788 0000000000000000
> 0x0000000047001b60:   00000007ea4d0e58 0000000000000000
> 0x0000000047001b70:   0000000047001b98 0000000047001c00
> 0x0000000047001b80:   00002aaaab02296e 00000007ea4d16b8
> 0x0000000047001b90:   00002aaaab02b8d6 0000000000000001
> 0x0000000047001ba0:   00000000514505e8 00002aaaab022a82
> 0x0000000047001bb0:   00002aaac4f365f8 000000077bfff118
> 0x0000000047001bc0:   0000000047001bc0 00000007ea4beb73
> 0x0000000047001bd0:   0000000047001c38 00000007ea4c2f18
> 0x0000000047001be0:   0000000000000000 00000007ea4bebf0
> 0x0000000047001bf0:   0000000047001b98 0000000047001c20
> 0x0000000047001c00:   0000000047001c90 00002aaaab02285a
> 0x0000000047001c10:   0000000000000000 00000000ffffffff
> 0x0000000047001c20:   0000000000000001 00000000514505e8
> 0x0000000047001c30:   000000077c01bc68 000000077b6059e8
> 0x0000000047001c40:   0000000000000009 0000000000000000
> 0x0000000047001c50:   0000000047001c40 00000007ea4bf518
> 0x0000000047001c60:   0000000047001ce0 00000007ea4c2f18
> 0x0000000047001c70:   00000007ea74b790 00000007ea4bfac0
> 0x0000000047001c80:   0000000047001c20 0000000047001ce0 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 06:04:23 2011
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Fri, 22 Jul 2011 06:04:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1284) Accessing
 localhost:8080 using JBoss Web Native causes
 java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
In-Reply-To: <2087989740.53707.1310651303687.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <305644719.75729.1311329063723.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615842#comment-12615842 ] 

Remy Maucherat commented on AS7-1284:
-------------------------------------

More seriously, maybe this is the use of a direct (rather than a regular) ByteBuffer which causes the problem ? Do we plan to actually support this JVM (incl for native) ? (I hear there are other problems with native on OSX that are being resolved)

> Accessing localhost:8080 using JBoss Web Native causes java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1284
>                 URL: https://issues.jboss.org/browse/AS7-1284
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>         Environment: Darwin osx-en-jwegne.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) Client VM (build 20.1-b02-384, mixed mode)
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)
>            Reporter: Josef Wegner
>            Assignee: Remy Maucherat
>            Priority: Minor
>         Attachments: libtcnative-1.jnilib
>
>
> Hi,
> accessing http://localhost:8080 using JBoss Web Native 2.0.9 (self compiled for x64 and downloaded from http://www.jboss.org/jbossweb/downloads/jboss-native-2-0-9.html for i386) causes following stack trace:
> {quote}
> 15:23:18,710 ERROR [org.apache.coyote.http11.Http11AprProtocol] (http--127.0.0.1-8080-1) Error reading request, ignored: java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> 	at org.apache.tomcat.jni.Socket.setrbb(Native Method)
> 	at org.apache.coyote.http11.InternalAprInputBuffer.setSocket(InternalAprInputBuffer.java:202)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:825)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: java.lang.ClassNotFoundException: sun.nio.ch.DirectBuffer from [Module "org.jboss.as.web:main" from local module loader @39e87719 (roots: /Users/jwegne/Tools/jboss-as-web-7.0.0.Final/modules)]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
> 	... 6 more
> {quote}
> This happens with only when using JDK 1.6 provided by Apple. OpenJDK 1.7 (self-compiled) works, though.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 06:20:23 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Fri, 22 Jul 2011 06:20:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1232)
 :test-connection-in-pool is "useless"
In-Reply-To: <194589846.42083.1310133683764.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <853761899.75746.1311330023862.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefano Maestri resolved AS7-1232.
----------------------------------

    Resolution: Done


> :test-connection-in-pool is "useless"
> -------------------------------------
>
>                 Key: AS7-1232
>                 URL: https://issues.jboss.org/browse/AS7-1232
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 7.0.0.CR1
>            Reporter: Heiko Rupp
>            Assignee: Stefano Maestri
>
> I have defined a datasource like this:
> [domain at localhost:9999 data-source=postresDS] :read-resource
> {
>     "outcome" => "success",
>     "result" => {
>         "connection-url" => "jdbc:yadayada",
>         "driver-name" => "postgresql-9.0-801.jdbc4.jar",
> So obviously with an invalid driver.
> But still I get 
> [domain at localhost:9999 data-source=postresDS] :test-connection-in-pool
> {
>     "outcome" => "success",
>     "result" => undefined
> }
> which makes imho no sense.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 06:22:24 2011
From: jira-events at lists.jboss.org (wiktorowski maximilien (JIRA))
Date: Fri, 22 Jul 2011 06:22:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1369) persistence.xml in
 EAR/META-INF folder with <jar-file>
Message-ID: <31035573.75763.1311330144626.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

persistence.xml in EAR/META-INF folder with <jar-file>
------------------------------------------------------

                 Key: AS7-1369
                 URL: https://issues.jboss.org/browse/AS7-1369
             Project: Application Server 7
          Issue Type: Bug
            Reporter: wiktorowski maximilien


adding persistence.xml in META-INF dir of an ear like this
?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence" 
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd" 
             version="2.0">
	<persistence-unit name="mypersistencunit">
           ...
           <jar-file>lib/myjpa.jar</jar-file>

result in exception:
Caused by: java.lang.RuntimeException: error trying to scan <jar-file>: vfs:/c:/JBoss/jboss-as-7.0.0.Final/bin/content/lib/myjpa.jar

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 06:26:24 2011
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 22 Jul 2011 06:26:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-193)
 RpcDispatcher.callRemoteMethod(s) should add "throws Exception" to
 signature
Message-ID: <1968767203.75766.1311330384198.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615844#comment-12615844 ] 

Bela Ban commented on JGRP-193:
-------------------------------

This was finally done in 3.0 !

> RpcDispatcher.callRemoteMethod(s) should add "throws Exception" to signature
> ----------------------------------------------------------------------------
>
>                 Key: JGRP-193
>                 URL: https://issues.jboss.org/browse/JGRP-193
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.2.8, 2.2.9, 2.2.9.1, 2.3, 2.4, 2.5, 3.x
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.0
>
>
> This will requirec code  changes to callers of these methods, so this will make it not API compatible with previous versions

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 06:52:24 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Fri, 22 Jul 2011 06:52:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1342)
 :test-connection-in-pool fails in a strange way
In-Reply-To: <1352163347.62821.1311082103928.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1480607502.75778.1311331944038.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615847#comment-12615847 ] 

Stefano Maestri commented on AS7-1342:
--------------------------------------

The problem is that it isn't a valid jndiName. DS currently support only java:/ and java:jboss/ namespace.

> :test-connection-in-pool fails in a strange way
> -----------------------------------------------
>
>                 Key: AS7-1342
>                 URL: https://issues.jboss.org/browse/AS7-1342
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 7.0.0.Final
>            Reporter: Heiko Rupp
>            Assignee: Stefano Maestri
>
> [11:54:03] <+pilhuhn> maeste hi
> [11:54:06] <+pilhuhn> what does this mean:
> [11:54:07] <+pilhuhn> [domain at localhost:9999 data-source=lalaDS] :test-connection-in-pool
> [11:54:07] <+pilhuhn> {
> [11:54:07] <+pilhuhn>    "outcome" => "failed",
> [11:54:07] <+pilhuhn>    "failure-description" => "failed to invoke operation: failed to match pool. Check JndiName: lalaJNDI",
> [11:54:57] <+maeste> that jndiName is not matched
> [11:55:19] <+pilhuhn> matched by?
> [11:55:34] <+maeste> by the runtime connection invoker
> [11:55:35] <+pilhuhn> If it is invalid, creation of the datasource should have failed ?
> [11:56:01] <+maeste> BTW maybe it'0s a bug when ds name and jndiName are not the same I'll check
> [11:56:14] <+pilhuhn> [domain at localhost:9999 data-source=lalaDS] :read-resource
> [11:56:14] <+pilhuhn> {
> [11:56:14] <+pilhuhn>    "outcome" => "success",
> [11:56:14] <+pilhuhn>    "result" => {
> [11:56:14] <+pilhuhn>        "background-validation" => undefined,
> [11:56:14] <+pilhuhn>        "background-validation-minutes" => undefined,
> [11:56:14] <+pilhuhn>        "blocking-timeout-wait-millis" => undefined,
> [11:56:14] <+pilhuhn>        "connection-url" => "jdbc:lala",
> [11:56:14] <+pilhuhn>        "driver-name" => "postgresql-9.0-801.jdbc4.jar",
> [11:56:14] <+pilhuhn>        "idle-timeout-minutes" => undefined,
> [11:56:14] <+pilhuhn>        "jndi-name" => "lalaJNDI",
> [11:56:38] <+pilhuhn> I did define an invalid connection URL (on purpose)
> [11:56:39] <+maeste> yup probably the problem is mine
> [11:56:49] <+maeste> I'll have a look this afternoon
> [11:57:53] ChanServ sets mode +v Jaikiran
> [11:57:54] <+pilhuhn> ok

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 07:06:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 07:06:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-478) Security checks when
 recursively reading resources
In-Reply-To: <1563038735.607.1296224979728.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1789920000.75807.1311332783836.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated AS7-478:
---------------------------------

    Fix Version/s: 7.1.0.CR1
                       (was: 7.1.0.Alpha1)


> Security checks when recursively reading resources
> --------------------------------------------------
>
>                 Key: AS7-478
>                 URL: https://issues.jboss.org/browse/AS7-478
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>    Affects Versions: 7.0.0.Alpha1
>            Reporter: Emanuel Muckenhuber
>            Assignee: Darran Lofthouse
>             Fix For: 7.1.0.CR1
>
>
> Currently the "read-resource" operation (GlobalOperationHandlers.ReadResourceHandler) just clones the subModel when recursively reading resources. We need to make sure that to also check the permissions for the children a node contains.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 07:12:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 07:12:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1370) Domain Management -
 Add support for database authentication.
Message-ID: <450820088.75821.1311333143609.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Domain Management - Add support for database authentication.
------------------------------------------------------------

                 Key: AS7-1370
                 URL: https://issues.jboss.org/browse/AS7-1370
             Project: Application Server 7
          Issue Type: Task
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 7.1.0.Beta1


It should be possible to define a database authentication element for authentication of incoming connections against a database.

Ideally the password should be obtainable from the database to allow us to use DIGEST authentication but if not a fallback to verify the password should be supported.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 07:18:24 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 07:18:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1371) Domain Management -
 Support for database connection pool in non AS process.
Message-ID: <1856981771.75836.1311333504015.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Domain Management - Support for database connection pool in non AS process.
---------------------------------------------------------------------------

                 Key: AS7-1371
                 URL: https://issues.jboss.org/browse/AS7-1371
             Project: Application Server 7
          Issue Type: Task
          Components: Domain Management
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 7.1.0.Beta1


We need to support authentication for users stored in database, the domain management is in a non-AS process so we also need a pool of database connections.

These connections will be used to read only from the database, other than the isolation offered by the driver we should not require any advanced transaction support.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 07:20:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 07:20:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1372) Domain Management -
 Enable silent authentication using Kerberos
Message-ID: <1312215154.75843.1311333623915.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Domain Management - Enable silent authentication using Kerberos
---------------------------------------------------------------

                 Key: AS7-1372
                 URL: https://issues.jboss.org/browse/AS7-1372
             Project: Application Server 7
          Issue Type: Task
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 7.1.0.Beta1


It should be possible for users to authenticate for domain management using Kerberos.

Over the HTTP interface this will be SPNEGO, for the Native connection we use SASL so can use GSSAPI

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 07:27:23 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Fri, 22 Jul 2011 07:27:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1342)
 :test-connection-in-pool fails in a strange way
In-Reply-To: <1352163347.62821.1311082103928.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <98390772.75854.1311334043657.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615857#comment-12615857 ] 

Heiko Rupp commented on AS7-1342:
---------------------------------

But then, adding a DS with such an invalid JNDI name should fail in the first place.

> :test-connection-in-pool fails in a strange way
> -----------------------------------------------
>
>                 Key: AS7-1342
>                 URL: https://issues.jboss.org/browse/AS7-1342
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 7.0.0.Final
>            Reporter: Heiko Rupp
>            Assignee: Stefano Maestri
>
> [11:54:03] <+pilhuhn> maeste hi
> [11:54:06] <+pilhuhn> what does this mean:
> [11:54:07] <+pilhuhn> [domain at localhost:9999 data-source=lalaDS] :test-connection-in-pool
> [11:54:07] <+pilhuhn> {
> [11:54:07] <+pilhuhn>    "outcome" => "failed",
> [11:54:07] <+pilhuhn>    "failure-description" => "failed to invoke operation: failed to match pool. Check JndiName: lalaJNDI",
> [11:54:57] <+maeste> that jndiName is not matched
> [11:55:19] <+pilhuhn> matched by?
> [11:55:34] <+maeste> by the runtime connection invoker
> [11:55:35] <+pilhuhn> If it is invalid, creation of the datasource should have failed ?
> [11:56:01] <+maeste> BTW maybe it'0s a bug when ds name and jndiName are not the same I'll check
> [11:56:14] <+pilhuhn> [domain at localhost:9999 data-source=lalaDS] :read-resource
> [11:56:14] <+pilhuhn> {
> [11:56:14] <+pilhuhn>    "outcome" => "success",
> [11:56:14] <+pilhuhn>    "result" => {
> [11:56:14] <+pilhuhn>        "background-validation" => undefined,
> [11:56:14] <+pilhuhn>        "background-validation-minutes" => undefined,
> [11:56:14] <+pilhuhn>        "blocking-timeout-wait-millis" => undefined,
> [11:56:14] <+pilhuhn>        "connection-url" => "jdbc:lala",
> [11:56:14] <+pilhuhn>        "driver-name" => "postgresql-9.0-801.jdbc4.jar",
> [11:56:14] <+pilhuhn>        "idle-timeout-minutes" => undefined,
> [11:56:14] <+pilhuhn>        "jndi-name" => "lalaJNDI",
> [11:56:38] <+pilhuhn> I did define an invalid connection URL (on purpose)
> [11:56:39] <+maeste> yup probably the problem is mine
> [11:56:49] <+maeste> I'll have a look this afternoon
> [11:57:53] ChanServ sets mode +v Jaikiran
> [11:57:54] <+pilhuhn> ok

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 07:29:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 07:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-977) Dynamic Detection of
 SPNEGO auth method and adding of NegotiationAuthenticator
In-Reply-To: <2043405000.14760.1307616899963.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <402210048.75858.1311334163736.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated AS7-977:
---------------------------------

    Fix Version/s: 7.1.0.Beta1
                       (was: 7.1.0.Alpha1)


> Dynamic Detection of SPNEGO auth method and adding of NegotiationAuthenticator
> ------------------------------------------------------------------------------
>
>                 Key: AS7-977
>                 URL: https://issues.jboss.org/browse/AS7-977
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Security, Web
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 7.1.0.Beta1
>
>
> Previously a mapping for the SPNEGO auth method and the authenticator had to be manually defined, this capability is not present in AS7 however it is suggested that alternatively we can detect the auth method ourselves and dynamically add the valve - this seems cleaner as it potentially allows SPNEGO to be added/removed from a server without manual configuration being required.
> It is suggested to look at the following code for an example where a valve has been added dynamically before: -
>   org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor in the JPA subsystem.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 07:29:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 07:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-949) JBoss Negotiation
 Toolkit shoud not be required to depend on org.jboss.logmanager
In-Reply-To: <60953986.8532.1307447159395.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <435661245.75864.1311334163968.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated AS7-949:
---------------------------------

    Fix Version/s: 7.1.0.Beta1
                       (was: 7.1.0.Alpha1)


> JBoss Negotiation Toolkit shoud not be required to depend on org.jboss.logmanager
> ---------------------------------------------------------------------------------
>
>                 Key: AS7-949
>                 URL: https://issues.jboss.org/browse/AS7-949
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Modules
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 7.1.0.Beta1
>
>
> Without defining the dependency the following is reported even though org.jboss.logging has the dependency defined: -
>    1.
>       12:01:15,299 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/jboss-negotiation-toolkit].[SecurityDomainTest]] (http-localhost.localdomain-127.0.0.1-8080-1) Servlet.service() for servlet SecurityDomainTest threw exception: java.lang.ClassNotFoundException: org.jboss.logmanager.Logger$AttachmentKey from [Module "deployment.jboss-negotiation-toolkit.war:main" from Service Module Loader]
>    2.
>               at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:188) [:1.0.0.CR3]
>    3.
>               at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358) [:1.0.0.CR3]
>    4.
>               at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330) [:1.0.0.CR3]
>    5.
>               at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307) [:1.0.0.CR3]
>    6.
>               at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101) [:1.0.0.CR3]
>    7.
>               at org.jboss.logging.JBossLogManagerProvider.<clinit>(JBossLogManagerProvider.java:36) [jboss-logging-3.0.0.Beta5.jar:]
>    8.
>               at org.jboss.logging.LoggerProviders.findProvider(LoggerProviders.java:33) [jboss-logging-3.0.0.Beta5.jar:]
>    9.
>               at org.jboss.logging.LoggerProviders.<clinit>(LoggerProviders.java:28) [jboss-logging-3.0.0.Beta5.jar:]
>   10.
>               at org.jboss.logging.Logger.getLogger(Logger.java:2164) [jboss-logging-3.0.0.Beta5.jar:]
>   11.
>               at org.jboss.logging.Logger.getLogger(Logger.java:2189) [jboss-logging-3.0.0.Beta5.jar:]
>   12.
>               at org.jboss.security.negotiation.toolkit.SecurityDomainTestServlet.doGet(SecurityDomainTestServlet.java:59) [classes:]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 07:59:24 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 07:59:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-777) Switchable Nonce
 Handling Strategy for HTTP DigestAuthenticator
In-Reply-To: <1213849935.1023.1305313610760.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1034133510.75941.1311335964001.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated AS7-777:
---------------------------------

    Fix Version/s: 7.1.0.Beta1
                       (was: 7.1.0.Alpha1)


> Switchable Nonce Handling Strategy for HTTP DigestAuthenticator
> ---------------------------------------------------------------
>
>                 Key: AS7-777
>                 URL: https://issues.jboss.org/browse/AS7-777
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 7.1.0.Beta1
>
>
> Allow the nonce strategy to be switchable: -
> 1 - Real 'Number Used Once' - i.e. new nonce for each request.
> 2 - Nonce per connection i.e. as long as a connection is kept alive allow re-use of nonce - new nonce on new connection.
> 3 - Timed nonce - Generate a nonce with a server secret and timestamp, nonce will be accepted for a validity period.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 08:03:24 2011
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Fri, 22 Jul 2011 08:03:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-8297) Weld throws error
 No active contexts for scope type javax.enterprise.context.RequestScoped
Message-ID: <2105534467.75961.1311336204374.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBAS-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615869#comment-12615869 ] 

Ales Justin commented on JBAS-8297:
-----------------------------------

>> A web build from the AS 7 branch is not going to be directly compatible.
How much effort is to port the changes / patch?


> Weld throws error No active contexts for scope type javax.enterprise.context.RequestScoped
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-8297
>                 URL: https://issues.jboss.org/browse/JBAS-8297
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>          Components: Weld/CDI
>         Environment: JBoss 6.0.0.M2, Windows XP SP3
>            Reporter: Marcos Antonio
>            Assignee: Remy Maucherat
>             Fix For: 6.1.0
>
>         Attachments: solicitacoes.zip
>
>
> 2010-04-22 09:55:36,484 WARN  [org.apache.catalina.authenticator.FormAuthenticator] (http-127.0.0.1-8080-1) Unexpected error forwarding to login page: javax.servlet.ServletException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 08:11:23 2011
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Fri, 22 Jul 2011 08:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1373) Setting EJB's
 InjectionTarget does not work
Message-ID: <816583500.75986.1311336683637.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Setting EJB's InjectionTarget does not work
-------------------------------------------

                 Key: AS7-1373
                 URL: https://issues.jboss.org/browse/AS7-1373
             Project: Application Server 7
          Issue Type: Bug
          Components: CDI / Weld
    Affects Versions: 7.0.0.Final
            Reporter: Jozef Hartinger
            Assignee: Stuart Douglas
            Priority: Blocker
             Fix For: 7.0.1.Final


Having an EJB

{code}
@Singleton
public class Bus {

    private boolean initialized = false;

    public boolean isInitialized() {
        return initialized;
    }

    public void setInitialized(boolean initialized) {
        this.initialized = initialized;
    }
}
{code}

and a CDI extension that wraps EJB's InjectionTarget

{code}
public class WrappingExtension implements Extension {

    public void wrapInjectionTarget(@Observes ProcessInjectionTarget<Bus> event)
    {
        final InjectionTarget<Bus> injectionTarget = event.getInjectionTarget();
        event.setInjectionTarget(new ForwardingInjectionTarget<Bus>() {

            @Override
            public void inject(Bus instance, CreationalContext<Bus> ctx) {
                super.inject(instance, ctx);
                instance.setInitialized(true);
            }

            @Override
            public InjectionTarget<Bus> getDelegate() {
                return injectionTarget;
            }
        });
    }
}
{code}

the InjectionTarget implementation is never invoked. When the Bus bean is changed to a CDI bean (@Singleton annotation is removed), the InjectionTarget implementation is invoked as expected.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 08:15:23 2011
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Fri, 22 Jul 2011 08:15:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1373) Setting EJB's
 InjectionTarget does not work
In-Reply-To: <816583500.75986.1311336683637.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1343145378.76004.1311336923783.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615871#comment-12615871 ] 

Jozef Hartinger commented on AS7-1373:
--------------------------------------

Testcase https://github.com/jharting/jboss-as/tree/AS7-1373-testcase

> Setting EJB's InjectionTarget does not work
> -------------------------------------------
>
>                 Key: AS7-1373
>                 URL: https://issues.jboss.org/browse/AS7-1373
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 7.0.0.Final
>            Reporter: Jozef Hartinger
>            Assignee: Stuart Douglas
>            Priority: Blocker
>             Fix For: 7.0.1.Final
>
>
> Having an EJB
> {code}
> @Singleton
> public class Bus {
>     private boolean initialized = false;
>     public boolean isInitialized() {
>         return initialized;
>     }
>     public void setInitialized(boolean initialized) {
>         this.initialized = initialized;
>     }
> }
> {code}
> and a CDI extension that wraps EJB's InjectionTarget
> {code}
> public class WrappingExtension implements Extension {
>     public void wrapInjectionTarget(@Observes ProcessInjectionTarget<Bus> event)
>     {
>         final InjectionTarget<Bus> injectionTarget = event.getInjectionTarget();
>         event.setInjectionTarget(new ForwardingInjectionTarget<Bus>() {
>             @Override
>             public void inject(Bus instance, CreationalContext<Bus> ctx) {
>                 super.inject(instance, ctx);
>                 instance.setInitialized(true);
>             }
>             @Override
>             public InjectionTarget<Bus> getDelegate() {
>                 return injectionTarget;
>             }
>         });
>     }
> }
> {code}
> the InjectionTarget implementation is never invoked. When the Bus bean is changed to a CDI bean (@Singleton annotation is removed), the InjectionTarget implementation is invoked as expected.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 08:19:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 08:19:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1374) Domain Management -
 Ensure we keep Native connections alive where appropriate
Message-ID: <2040058030.76021.1311337163611.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Domain Management - Ensure we keep Native connections alive where appropriate
-----------------------------------------------------------------------------

                 Key: AS7-1374
                 URL: https://issues.jboss.org/browse/AS7-1374
             Project: Application Server 7
          Issue Type: Task
          Components: Domain Management, Remoting
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 7.1.0.Beta1


Establishing a connection can generally also involve negotiating the security before the connection is first used, this has the potential to become a major performance drain especially if the management load is high (management can be everything from updating the model to querying metrics).  

This task is to ensure we keep the connections alive where it makes sense.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 08:23:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 08:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1054) The CallbackHandler
 is called multiple times on the client side with Remoting / Managent
 Interface
In-Reply-To: <1254375172.5285.1308507743640.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2096318516.76033.1311337403760.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated AS7-1054:
----------------------------------

    Fix Version/s: 7.1.0.Beta1
                       (was: 7.1.0.Alpha1)


> The CallbackHandler is called multiple times on the client side with Remoting / Managent Interface
> --------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1054
>                 URL: https://issues.jboss.org/browse/AS7-1054
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Remoting, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 7.1.0.Beta1
>
>
> This may be a side effect of the current problems where Remoting is looped to establish the connection but it means that we need to cache the users username and password from the first attempt so we don't keep prompting them - the problem then is we do not know if the subsequent call is because their values were invalid or just because of the retries.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 08:23:24 2011
From: jira-events at lists.jboss.org (=?UTF-8?Q?Tom=C3=A1=C5=A1_Reme=C5=A1_=28JIRA=29?=)
Date: Fri, 22 Jul 2011 08:23:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1375)
 UnsupportedDataTypeException sending email
Message-ID: <244896876.76044.1311337404128.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

UnsupportedDataTypeException sending email 
-------------------------------------------

                 Key: AS7-1375
                 URL: https://issues.jboss.org/browse/AS7-1375
             Project: Application Server 7
          Issue Type: Bug
         Environment: jdk-u26, jboss-as-7.1.0.Alpha1-SNAPSHOT(07/22/2011)
            Reporter: Tom?? Reme?


Seam 3 send mail example fails on:
javax.activation.UnsupportedDataTypeException: no object DCH for MIME type multipart/mixed; 
	boundary="----=_Part_1_340486764.1311336438303"
	at javax.activation.ObjectDataContentHandler.writeTo(DataHandler.java:905) [activation-1.1.1.jar:1.1.1]
	at javax.activation.DataHandler.writeTo(DataHandler.java:330) [activation-1.1.1.jar:1.1.1]
	at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:1476) [mail-1.4.4.jar:1.4.4]
	at javax.mail.internet.MimeMessage.writeTo(MimeMessage.java:1772) [mail-1.4.4.jar:1.4.4]
	at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:1099) [mail-1.4.4.jar:1.4.4]
	... 42 more


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Fri Jul 22 08:27:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 22 Jul 2011 08:27:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1376) Implement EE.10
 Application Clients
Message-ID: <1295260968.76049.1311337643725.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Implement EE.10 Application Clients
-----------------------------------

                 Key: AS7-1376
                 URL: https://issues.jboss.org/browse/AS7-1376
             Project: Application Server 7
          Issue Type: Task
          Components: EE
            Reporter: Carlo de Wolf
            Assignee: David Lloyd
            Priority: Critical
             Fix For: 7.1.0.CR1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 08:29:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 08:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1053) Revisit requirement
 that realm name needs to match endpoint name with Remoting / Native
 Interface
In-Reply-To: <1890847156.5282.1308507083615.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1666468318.76060.1311337763618.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated AS7-1053:
----------------------------------

    Fix Version/s: 7.1.0.Beta1
                       (was: 7.1.0.Alpha1)


> Revisit requirement that realm name needs to match endpoint name with Remoting / Native Interface
> -------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1053
>                 URL: https://issues.jboss.org/browse/AS7-1053
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Remoting
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 7.1.0.Beta1
>
>
> It is reported that the realm used for the endpoint needs to match the endpoint name - for this reason the realm appears as 'endpoint'
> The realm should actually match the name of the realm being used as this is to inform the user of the realm they are using.  This may also need expanding to multiple realms in the future so users in different realms can all authenticate against the same resource.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 08:31:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Fri, 22 Jul 2011 08:31:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1377) RA logs under
	"datasources"
Message-ID: <2002395954.76063.1311337883621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

RA logs under "datasources"
---------------------------

                 Key: AS7-1377
                 URL: https://issues.jboss.org/browse/AS7-1377
             Project: Application Server 7
          Issue Type: Bug
          Components: JCA
            Reporter: Heiko Braun
            Assignee: Jesper Pedersen
             Fix For: 7.1.0.CR1


See ResourceAdaptersExtension.java


> private static final Logger log = Logger.getLogger("org.jboss.as.datasources");



--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 08:33:24 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 08:33:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1104) JBoss SASL Provider
 Registration should be within PrivilegedAction
In-Reply-To: <116732591.17524.1308852263666.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <126742107.76068.1311338004238.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated AS7-1104:
----------------------------------

    Fix Version/s: 7.1.0.Beta1
                       (was: 7.1.0.Alpha1)


> JBoss SASL Provider Registration should be within PrivilegedAction
> ------------------------------------------------------------------
>
>                 Key: AS7-1104
>                 URL: https://issues.jboss.org/browse/AS7-1104
>             Project: Application Server 7
>          Issue Type: Task
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 7.1.0.Beta1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 08:33:25 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 08:33:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1107) Upgrade to JBoss SASL
 1.0.0.Beta2 to enabled Digest
In-Reply-To: <314319465.17734.1308857783905.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <917219404.76088.1311338005282.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated AS7-1107:
----------------------------------

    Fix Version/s: 7.1.0.Beta1
                       (was: 7.1.0.Alpha1)


> Upgrade to JBoss SASL 1.0.0.Beta2 to enabled Digest
> ---------------------------------------------------
>
>                 Key: AS7-1107
>                 URL: https://issues.jboss.org/browse/AS7-1107
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 7.1.0.Beta1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 08:35:24 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 08:35:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1167) Implement PLAIN SASL
	mechanism
In-Reply-To: <599658245.31945.1309519824233.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <297187959.76095.1311338124053.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated AS7-1167:
----------------------------------

    Fix Version/s: 7.1.0.Beta1
                       (was: 7.1.0.Alpha1)


> Implement PLAIN SASL mechanism
> ------------------------------
>
>                 Key: AS7-1167
>                 URL: https://issues.jboss.org/browse/AS7-1167
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 7.1.0.Beta1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 08:35:24 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 22 Jul 2011 08:35:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1377) RA logs under
	"datasources"
In-Reply-To: <2002395954.76063.1311337883621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1905877834.76104.1311338124509.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen reassigned AS7-1377:
------------------------------------

    Assignee: Jeff Zhang  (was: Jesper Pedersen)


> RA logs under "datasources"
> ---------------------------
>
>                 Key: AS7-1377
>                 URL: https://issues.jboss.org/browse/AS7-1377
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.CR1
>
>
> See ResourceAdaptersExtension.java
> > private static final Logger log = Logger.getLogger("org.jboss.as.datasources");

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 08:37:24 2011
From: jira-events at lists.jboss.org (Rostislav Svoboda (JIRA))
Date: Fri, 22 Jul 2011 08:37:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1378) Make module directory
 configurable using .sh/.bat run scripts
Message-ID: <37037143.76122.1311338244771.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Make module directory configurable using .sh/.bat run scripts
-------------------------------------------------------------

                 Key: AS7-1378
                 URL: https://issues.jboss.org/browse/AS7-1378
             Project: Application Server 7
          Issue Type: Feature Request
            Reporter: Rostislav Svoboda
             Fix For: 7.1.0.Alpha1


Make module directory configurable using .sh/.bat run scripts, currently you can specify configuration location using '--server-config' or '--domain-config' + '--host-config' , location of modules directory should be configurable too.

It's necessary to make changes on .bat/.sh files level to make module directory configurable. 
Currently it's hard-coded to use module directory under JBOSS_HOME directory
{code}
-mp \"$JBOSS_HOME/modules\" \
{code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 08:39:24 2011
From: jira-events at lists.jboss.org (Rostislav Svoboda (JIRA))
Date: Fri, 22 Jul 2011 08:39:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1378) Make module directory
 configurable using .sh/.bat run scripts
In-Reply-To: <37037143.76122.1311338244771.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1208372085.76136.1311338364441.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rostislav Svoboda updated AS7-1378:
-----------------------------------

    Description: 
Make module directory configurable using .sh/.bat run scripts, currently you can specify configuration location using 'server-config' or 'domain-config' + 'host-config' parameters , location of modules directory should be configurable too.

It's necessary to make changes on .bat/.sh files level to make module directory configurable. 
Currently it's hard-coded to use module directory under JBOSS_HOME directory
{code}
...
-mp \"$JBOSS_HOME/modules\" \
...
{code}

  was:
Make module directory configurable using .sh/.bat run scripts, currently you can specify configuration location using '--server-config' or '--domain-config' + '--host-config' , location of modules directory should be configurable too.

It's necessary to make changes on .bat/.sh files level to make module directory configurable. 
Currently it's hard-coded to use module directory under JBOSS_HOME directory
{code}
-mp \"$JBOSS_HOME/modules\" \
{code}



> Make module directory configurable using .sh/.bat run scripts
> -------------------------------------------------------------
>
>                 Key: AS7-1378
>                 URL: https://issues.jboss.org/browse/AS7-1378
>             Project: Application Server 7
>          Issue Type: Feature Request
>            Reporter: Rostislav Svoboda
>             Fix For: 7.1.0.Alpha1
>
>
> Make module directory configurable using .sh/.bat run scripts, currently you can specify configuration location using 'server-config' or 'domain-config' + 'host-config' parameters , location of modules directory should be configurable too.
> It's necessary to make changes on .bat/.sh files level to make module directory configurable. 
> Currently it's hard-coded to use module directory under JBOSS_HOME directory
> {code}
> ...
> -mp \"$JBOSS_HOME/modules\" \
> ...
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 08:41:24 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 08:41:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-787) Create a dummy
 InitialDirContext to allow for testing.
In-Reply-To: <1743298765.1325.1305541500944.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1110481279.76142.1311338484357.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated AS7-787:
---------------------------------

    Fix Version/s: 7.1.0.Beta1
                       (was: 7.1.0.Alpha1)


> Create a dummy InitialDirContext to allow for testing.
> ------------------------------------------------------
>
>                 Key: AS7-787
>                 URL: https://issues.jboss.org/browse/AS7-787
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 7.1.0.Beta1
>
>
> The testing of any LDAP configuration brings in the dependency on an LDAP server, this is fine for major QA testing but not so fine for the testsuite run in multiple environments.
> This task is to either find an existing implementation we can use or to implement a dummy InitialDirContext that can simulate the connection to LDAP allowing testing of the LDAP code.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 08:43:24 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Fri, 22 Jul 2011 08:43:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1379) Provide the ability
 to update RA attributes
Message-ID: <1278138426.76165.1311338604308.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Provide the ability to update RA attributes
-------------------------------------------

                 Key: AS7-1379
                 URL: https://issues.jboss.org/browse/AS7-1379
             Project: Application Server 7
          Issue Type: Feature Request
          Components: JCA
            Reporter: Heiko Braun
            Assignee: Jeff Zhang
             Fix For: 7.1.0.Beta1


most of the attributes seem to be read only.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 08:43:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 22 Jul 2011 08:43:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1380) EJB component
 annotation scanning deployers should ignore component declaring annotations
 on interfaces
Message-ID: <144302072.76168.1311338604371.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

EJB component annotation scanning deployers should ignore component declaring annotations on interfaces
-------------------------------------------------------------------------------------------------------

                 Key: AS7-1380
                 URL: https://issues.jboss.org/browse/AS7-1380
             Project: Application Server 7
          Issue Type: Bug
          Components: EE
    Affects Versions: 7.0.0.Final
            Reporter: jaikiran pai
            Assignee: jaikiran pai


Consider this interface:

{code}
@Stateless
public interface IAmAnInterface {
..
{code}

We should not be picking up this interface as a component. We should only pickup these annotations from a class. We can just log a WARN about this incorrect annotation and skip its processing.



--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 08:43:24 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Fri, 22 Jul 2011 08:43:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1381) Make RA config
 properties sub resources
Message-ID: <796812033.76172.1311338604471.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Make RA config properties sub resources
---------------------------------------

                 Key: AS7-1381
                 URL: https://issues.jboss.org/browse/AS7-1381
             Project: Application Server 7
          Issue Type: Feature Request
          Components: JCA
            Reporter: Heiko Braun
            Assignee: Jeff Zhang
             Fix For: 7.1.0.CR1


Take a look how system properties are represented. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 08:45:24 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 08:45:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-825) Fix or remove @Ignore
 in ParseAndMarshalModelsTestCase
In-Reply-To: <1386457314.7033.1305666001060.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <497318688.76185.1311338724519.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated AS7-825:
---------------------------------

    Fix Version/s: 7.1.0.Beta1
                       (was: 7.1.0.CR1)


Need to check but I think this is already resolved.

> Fix or remove @Ignore in ParseAndMarshalModelsTestCase
> ------------------------------------------------------
>
>                 Key: AS7-825
>                 URL: https://issues.jboss.org/browse/AS7-825
>             Project: Application Server 7
>          Issue Type: Sub-task
>            Reporter: Thomas Diesler
>            Assignee: Darran Lofthouse
>             Fix For: 7.1.0.Beta1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 08:47:24 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Fri, 22 Jul 2011 08:47:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1310) Manage resource
 adapters through web console
In-Reply-To: <1962862106.59724.1310983103616.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <672225322.76201.1311338844169.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated AS7-1310:
-----------------------------

    Comment: was deleted

(was: Current beta is upstream. Waiting on the dependencies to be resolved)


> Manage resource adapters through web console
> --------------------------------------------
>
>                 Key: AS7-1310
>                 URL: https://issues.jboss.org/browse/AS7-1310
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Console
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>              Labels: console_prio
>             Fix For: 7.1.0.CR1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 08:55:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 08:55:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1382) Ensure domain
 security is fully manageable
Message-ID: <870476796.76284.1311339323821.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Ensure domain security is fully manageable
------------------------------------------

                 Key: AS7-1382
                 URL: https://issues.jboss.org/browse/AS7-1382
             Project: Application Server 7
          Issue Type: Task
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 7.1.0.Beta1


At the moment the management operations are fairly coarse based on the operations generated from parsing the XML, these should be enhanced to allow more fine grained management from the admin clients. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 08:59:24 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 08:59:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-848) Add
 ModelNodeDescription(s) for <management> definition and updated
 <management-interfaces>
In-Reply-To: <1817235960.13361.1305810660924.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1521881725.76324.1311339564765.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated AS7-848:
---------------------------------

    Fix Version/s: 7.1.0.Beta1
                       (was: 7.1.0.Alpha1)


> Add ModelNodeDescription(s) for <management> definition and updated <management-interfaces>
> -------------------------------------------------------------------------------------------
>
>                 Key: AS7-848
>                 URL: https://issues.jboss.org/browse/AS7-848
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 7.1.0.Beta1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 09:03:38 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 22 Jul 2011 09:03:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-635) Wrong classloader
 used for plugins
Message-ID: <503286272.76356.1311339818188.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Wrong classloader used for plugins
----------------------------------

                 Key: JBJCA-635
                 URL: https://issues.jboss.org/browse/JBJCA-635
             Project: IronJacamar
          Issue Type: Bug
          Components: JDBC
    Affects Versions: 1.0.0.Final
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
            Priority: Critical
             Fix For: 1.0.1.Final, 1.1.0.Alpha1


The wrong classloader is used to load plugins for the JDBC resource adapter

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 09:05:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 09:05:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-849) Add support for
 <management> element to domain.xml and add security realm extension i.e. an
 extends attribute.
In-Reply-To: <1283832887.13369.1305811260911.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <88772084.76362.1311339923697.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated AS7-849:
---------------------------------

    Fix Version/s: 7.1.0.Beta1
                       (was: 7.1.0.Alpha1)


> Add support for <management> element to domain.xml and add security realm extension i.e. an extends attribute.
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-849
>                 URL: https://issues.jboss.org/browse/AS7-849
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 7.1.0.Beta1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 09:07:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 09:07:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-851) Add some form of
	:whoami operation
In-Reply-To: <1075310726.13529.1305815640995.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1858063505.76373.1311340043949.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated AS7-851:
---------------------------------

    Fix Version/s: 7.1.0.Beta1
                       (was: 7.1.0.Alpha1)


> Add some form of :whoami operation
> ----------------------------------
>
>                 Key: AS7-851
>                 URL: https://issues.jboss.org/browse/AS7-851
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 7.1.0.Beta1
>
>
> Connectivity to the server can make use of authentication automatically handled by either the web broswer or in some cases possibly a CLI using a local Kerberos ticket.
> This issue is to add a :whoami operation to verify who the connection is running as so the client can see they are connected as the expected user.
> Later this may also be expanded to make it possible to query what a client can actually do so operations a client can not perform can be potentially hidden / masked.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 09:13:24 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 22 Jul 2011 09:13:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1381) Make RA config
 properties sub resources
In-Reply-To: <796812033.76172.1311338604471.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1201556668.76432.1311340404118.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615903#comment-12615903 ] 

Jesper Pedersen commented on AS7-1381:
--------------------------------------

What "attributes" ?

If you mean the resource adapter config-property's, then they are only writeable if the resource adapter is version 1.6, and supports dynamic updates. That should already be supported.

> Make RA config properties sub resources
> ---------------------------------------
>
>                 Key: AS7-1381
>                 URL: https://issues.jboss.org/browse/AS7-1381
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.CR1
>
>
> Take a look how system properties are represented. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 09:15:24 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 22 Jul 2011 09:15:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1379) Provide the ability
 to update RA attributes
In-Reply-To: <1278138426.76165.1311338604308.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <883956572.76451.1311340524323.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615905#comment-12615905 ] 

Jesper Pedersen commented on AS7-1379:
--------------------------------------

What "attributes" ?

If you mean the resource adapter config-property's, then they are only writeable if the resource adapter is version 1.6, and supports dynamic updates. That should already be supported.


> Provide the ability to update RA attributes
> -------------------------------------------
>
>                 Key: AS7-1379
>                 URL: https://issues.jboss.org/browse/AS7-1379
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.Beta1
>
>
> most of the attributes seem to be read only.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 09:15:24 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 22 Jul 2011 09:15:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1381) Make RA config
 properties sub resources
In-Reply-To: <796812033.76172.1311338604471.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2004623545.76456.1311340524463.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated AS7-1381:
---------------------------------

    Comment: was deleted

(was: What "attributes" ?

If you mean the resource adapter config-property's, then they are only writeable if the resource adapter is version 1.6, and supports dynamic updates. That should already be supported.)


> Make RA config properties sub resources
> ---------------------------------------
>
>                 Key: AS7-1381
>                 URL: https://issues.jboss.org/browse/AS7-1381
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.CR1
>
>
> Take a look how system properties are represented. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 09:17:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Fri, 22 Jul 2011 09:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1379) Provide the ability
 to update RA attributes
In-Reply-To: <1278138426.76165.1311338604308.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1227237655.76463.1311340643709.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615906#comment-12615906 ] 

Heiko Braun commented on AS7-1379:
----------------------------------

I am talking about the model. Not the runtime. The DMR model doesn't allow atm.
The question how this impacts the runtime is a different story. For most cases I would assume a server restart is required.

> Provide the ability to update RA attributes
> -------------------------------------------
>
>                 Key: AS7-1379
>                 URL: https://issues.jboss.org/browse/AS7-1379
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.Beta1
>
>
> most of the attributes seem to be read only.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 09:19:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Fri, 22 Jul 2011 09:19:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1379) Provide the ability
 to update RA attributes
In-Reply-To: <1278138426.76165.1311338604308.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <983850240.76471.1311340763773.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615907#comment-12615907 ] 

Heiko Braun commented on AS7-1379:
----------------------------------

For instance the resource adapter "transaction-support" attribute. but also anything listed under "config-properties".

> Provide the ability to update RA attributes
> -------------------------------------------
>
>                 Key: AS7-1379
>                 URL: https://issues.jboss.org/browse/AS7-1379
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.Beta1
>
>
> most of the attributes seem to be read only.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 09:19:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Fri, 22 Jul 2011 09:19:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-1379) Provide
 the ability to update RA attributes
In-Reply-To: <1278138426.76165.1311338604308.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1739774040.76477.1311340763937.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615906#comment-12615906 ] 

Heiko Braun edited comment on AS7-1379 at 7/22/11 9:17 AM:
-----------------------------------------------------------

I am talking about the model. Not the runtime. The DMR model doesn't allow modifications atm. The question how this impacts the runtime is a different story. For most cases I would assume a server restart is required.

      was (Author: heiko.braun):
    I am talking about the model. Not the runtime. The DMR model doesn't allow atm.
The question how this impacts the runtime is a different story. For most cases I would assume a server restart is required.
  
> Provide the ability to update RA attributes
> -------------------------------------------
>
>                 Key: AS7-1379
>                 URL: https://issues.jboss.org/browse/AS7-1379
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.Beta1
>
>
> most of the attributes seem to be read only.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 09:23:24 2011
From: jira-events at lists.jboss.org (Abhijit Sarkar (JIRA))
Date: Fri, 22 Jul 2011 09:23:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1380) EJB component
 annotation scanning deployers should ignore component declaring annotations
 on interfaces
In-Reply-To: <144302072.76168.1311338604371.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <894349272.76507.1311341004867.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615910#comment-12615910 ] 

Abhijit Sarkar commented on AS7-1380:
-------------------------------------

I do not agree that @Stateless shouldn't be applied to an interface. The annotation target allows for interfaces and there is nothing in the spec preventing that. On the contrary, there are available examples which annotate similarly. JBoss AS should not warn the user against doing that. It may just ignore the annotation if present on an interface.

> EJB component annotation scanning deployers should ignore component declaring annotations on interfaces
> -------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1380
>                 URL: https://issues.jboss.org/browse/AS7-1380
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 7.0.0.Final
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> Consider this interface:
> {code}
> @Stateless
> public interface IAmAnInterface {
> ..
> {code}
> We should not be picking up this interface as a component. We should only pickup these annotations from a class. We can just log a WARN about this incorrect annotation and skip its processing.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 09:33:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 22 Jul 2011 09:33:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1380) EJB component
 annotation scanning deployers should ignore component declaring annotations
 on interfaces
In-Reply-To: <144302072.76168.1311338604371.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1304716092.76548.1311341603679.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615915#comment-12615915 ] 

jaikiran pai commented on AS7-1380:
-----------------------------------

I replied in the forum thread http://community.jboss.org/thread/169876?tstart=0


> EJB component annotation scanning deployers should ignore component declaring annotations on interfaces
> -------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1380
>                 URL: https://issues.jboss.org/browse/AS7-1380
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 7.0.0.Final
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> Consider this interface:
> {code}
> @Stateless
> public interface IAmAnInterface {
> ..
> {code}
> We should not be picking up this interface as a component. We should only pickup these annotations from a class. We can just log a WARN about this incorrect annotation and skip its processing.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 09:39:25 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 09:39:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1383) Domain Managent -
 Ensure current authenticated user is associated with current request /
 thread and is retrievable.
Message-ID: <728916726.76617.1311341965085.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Domain Managent - Ensure current authenticated user is associated with current request / thread and is retrievable.
-------------------------------------------------------------------------------------------------------------------

                 Key: AS7-1383
                 URL: https://issues.jboss.org/browse/AS7-1383
             Project: Application Server 7
          Issue Type: Task
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 7.1.0.Beta1


Initially for audit but also for other purposes the current user needs to be identifiable for the request being processed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 09:43:23 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Fri, 22 Jul 2011 09:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1384) Strange state after
	:reload
Message-ID: <1753481536.76865.1311342203978.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Strange state after :reload
---------------------------

                 Key: AS7-1384
                 URL: https://issues.jboss.org/browse/AS7-1384
             Project: Application Server 7
          Issue Type: Bug
          Components: Domain Management
            Reporter: Heiko Rupp
            Assignee: Brian Stansberry



7.1 snapshot


I did change a socket binding, so reload is needed. Did a /:read-resource
Then :reload

    },
    "response-headers" => {"process-state" => "reload-required"}
}
[standalone at localhost:9999 /] :reload
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
[standalone at localhost:9999 /] :reload
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}

I think after the reload (which succeeded) the process-state should no longer be "reload needed".

Also 

{"result" =>  } should be defined and not just null.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 09:45:23 2011
From: jira-events at lists.jboss.org (Michal Linhard (JIRA))
Date: Fri, 22 Jul 2011 09:45:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1385) make storeAsBinary
	configurable
Message-ID: <232705938.76868.1311342323827.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

make storeAsBinary configurable
-------------------------------

                 Key: AS7-1385
                 URL: https://issues.jboss.org/browse/AS7-1385
             Project: Application Server 7
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 7.0.0.Final
            Reporter: Michal Linhard
            Assignee: Paul Ferraro
            Priority: Critical


we need be able to turn on/off these infinispan config options
infinispan.configuration.storeAsBinary.enabled
infinispan.configuration.lazyDeserialization.enabled

it's not yet known what causes performance degradation in JBPAPP-6865,
but we need to be able to eliminate effect of these params

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 09:47:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 09:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1386) Add GSSAPI support to
	CLI
Message-ID: <201333697.76890.1311342443718.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Add GSSAPI support to CLI
-------------------------

                 Key: AS7-1386
                 URL: https://issues.jboss.org/browse/AS7-1386
             Project: Application Server 7
          Issue Type: Task
          Components: CLI, Domain Management
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 7.1.0.Beta1


Once the Native interface supports GSSAPI then the CLI will also need to support this.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 10:02:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 10:02:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-884) Support masking of
 password using Base64 for both domain model definitions of users and
 properties file definition of users.
In-Reply-To: <1457855264.21217.1306238702274.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1426360338.76906.1311343343663.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated AS7-884:
---------------------------------

    Fix Version/s: 7.1.0.Beta1
                       (was: 7.1.0.Alpha1)


> Support masking of password using Base64 for both domain model definitions of users and properties file definition of users.
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-884
>                 URL: https://issues.jboss.org/browse/AS7-884
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 7.1.0.Beta1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 10:04:27 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 10:04:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1102) Create PKCS#11
 Compitable Cryptographic Services for Domain Management
In-Reply-To: <2030558315.16365.1308838704569.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <521077319.76909.1311343467776.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated AS7-1102:
----------------------------------

    Fix Version/s: 7.1.0.Beta1
                       (was: 7.1.0.Alpha1)


> Create PKCS#11 Compitable Cryptographic Services for Domain Management
> ----------------------------------------------------------------------
>
>                 Key: AS7-1102
>                 URL: https://issues.jboss.org/browse/AS7-1102
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 7.1.0.Beta1
>
>
> Within domain management there are occasions where passwords need to be stored or keystores accessed either for encryption / decryption of password or to load the keys used for SSL exchanges.
> Commonly a password within code is used for password based encryption of other passwords, this obfuscates the password but does not over complicate the process of recovering the password, alternatively a local keystore can be used for the encryption but again everything is available on the local disk to recover the password.
> PKCS#11 will allow the cryptographic to be delegated to hardware which contains it's own protection against keys being made available.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 10:08:24 2011
From: jira-events at lists.jboss.org (Michal Linhard (JIRA))
Date: Fri, 22 Jul 2011 10:08:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1385) make storeAsBinary
	configurable
In-Reply-To: <232705938.76868.1311342323827.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <478573329.76922.1311343704057.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michal Linhard updated AS7-1385:
--------------------------------

    Priority: Major  (was: Critical)


OK, this doesn't seem so critical, because storeAsBinary shouldn't have much effect in remote access mode

> make storeAsBinary configurable
> -------------------------------
>
>                 Key: AS7-1385
>                 URL: https://issues.jboss.org/browse/AS7-1385
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.Final
>            Reporter: Michal Linhard
>            Assignee: Paul Ferraro
>
> we need be able to turn on/off these infinispan config options
> infinispan.configuration.storeAsBinary.enabled
> infinispan.configuration.lazyDeserialization.enabled
> it's not yet known what causes performance degradation in JBPAPP-6865,
> but we need to be able to eliminate effect of these params

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 10:14:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 10:14:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1387) Enable SSL for the
 Remoting/Native Interface
Message-ID: <161759202.76927.1311344063640.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Enable SSL for the Remoting/Native Interface
--------------------------------------------

                 Key: AS7-1387
                 URL: https://issues.jboss.org/browse/AS7-1387
             Project: Application Server 7
          Issue Type: Task
          Components: Domain Management, Remoting, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 7.1.0.Beta1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 10:14:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 10:14:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1388) Certificate based
	authentication.
Message-ID: <376962919.76928.1311344063662.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Certificate based authentication.
---------------------------------

                 Key: AS7-1388
                 URL: https://issues.jboss.org/browse/AS7-1388
             Project: Application Server 7
          Issue Type: Task
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 7.1.0.Beta1




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 10:18:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 10:18:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1037)
 WelcomeContextConsoleServlet needs additional work detecting redirect
 address.
In-Reply-To: <535945026.1780.1308241703828.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1407066654.76938.1311344303763.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated AS7-1037:
----------------------------------

    Fix Version/s: 7.1.0.Beta1
                       (was: 7.1.0.Alpha1)


> WelcomeContextConsoleServlet needs additional work detecting redirect address.
> ------------------------------------------------------------------------------
>
>                 Key: AS7-1037
>                 URL: https://issues.jboss.org/browse/AS7-1037
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Web
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 7.1.0.Beta1
>
>
> At the moment it assumes if https is available for the JBoss Web connector that it will be available for the console, likewise a non https request to to JBoss Web does not mean the request to the console should be non-https.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 10:35:26 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 22 Jul 2011 10:35:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1284) Accessing
 localhost:8080 using JBoss Web Native causes
 java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
In-Reply-To: <2087989740.53707.1310651303687.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1472034414.77009.1311345326091.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615930#comment-12615930 ] 

Brian Stansberry commented on AS7-1284:
---------------------------------------

Remy, sounds like Rich Sharples is the guy to ask that question.

> Accessing localhost:8080 using JBoss Web Native causes java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1284
>                 URL: https://issues.jboss.org/browse/AS7-1284
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>         Environment: Darwin osx-en-jwegne.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) Client VM (build 20.1-b02-384, mixed mode)
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)
>            Reporter: Josef Wegner
>            Assignee: Remy Maucherat
>            Priority: Minor
>         Attachments: libtcnative-1.jnilib
>
>
> Hi,
> accessing http://localhost:8080 using JBoss Web Native 2.0.9 (self compiled for x64 and downloaded from http://www.jboss.org/jbossweb/downloads/jboss-native-2-0-9.html for i386) causes following stack trace:
> {quote}
> 15:23:18,710 ERROR [org.apache.coyote.http11.Http11AprProtocol] (http--127.0.0.1-8080-1) Error reading request, ignored: java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> 	at org.apache.tomcat.jni.Socket.setrbb(Native Method)
> 	at org.apache.coyote.http11.InternalAprInputBuffer.setSocket(InternalAprInputBuffer.java:202)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:825)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: java.lang.ClassNotFoundException: sun.nio.ch.DirectBuffer from [Module "org.jboss.as.web:main" from local module loader @39e87719 (roots: /Users/jwegne/Tools/jboss-as-web-7.0.0.Final/modules)]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
> 	... 6 more
> {quote}
> This happens with only when using JDK 1.6 provided by Apple. OpenJDK 1.7 (self-compiled) works, though.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 10:37:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 22 Jul 2011 10:37:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1384) Strange state after
	:reload
In-Reply-To: <1753481536.76865.1311342203978.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2067202132.77012.1311345443628.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated AS7-1384:
----------------------------------

             Assignee:     (was: Brian Stansberry)
        Fix Version/s: 7.1.0.Alpha1
    Affects Version/s: 7.0.0.Final
          Description: 
7.1 snapshot


I did change a socket binding, so reload is needed. Did a /:read-resource
Then :reload

    },
    "response-headers" => {"process-state" => "reload-required"}
}
[standalone at localhost:9999 /] :reload
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
[standalone at localhost:9999 /] :reload
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}

I think after the reload (which succeeded) the process-state should no longer be "reload needed".

Also 

{"result" =>  } should be defined and not just null.

  was:

7.1 snapshot


I did change a socket binding, so reload is needed. Did a /:read-resource
Then :reload

    },
    "response-headers" => {"process-state" => "reload-required"}
}
[standalone at localhost:9999 /] :reload
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
[standalone at localhost:9999 /] :reload
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}

I think after the reload (which succeeded) the process-state should no longer be "reload needed".

Also 

{"result" =>  } should be defined and not just null.



> Strange state after :reload
> ---------------------------
>
>                 Key: AS7-1384
>                 URL: https://issues.jboss.org/browse/AS7-1384
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.0.0.Final
>            Reporter: Heiko Rupp
>             Fix For: 7.1.0.Alpha1
>
>
> 7.1 snapshot
> I did change a socket binding, so reload is needed. Did a /:read-resource
> Then :reload
>     },
>     "response-headers" => {"process-state" => "reload-required"}
> }
> [standalone at localhost:9999 /] :reload
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> [standalone at localhost:9999 /] :reload
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> I think after the reload (which succeeded) the process-state should no longer be "reload needed".
> Also 
> {"result" =>  } should be defined and not just null.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 10:51:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 22 Jul 2011 10:51:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-636) IronJacamar
	1.0.1.Final
Message-ID: <842374869.77093.1311346283717.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

IronJacamar 1.0.1.Final
-----------------------

                 Key: JBJCA-636
                 URL: https://issues.jboss.org/browse/JBJCA-636
             Project: IronJacamar
          Issue Type: Release
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.1.Final


Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&version=12317216

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 10:53:24 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 22 Jul 2011 10:53:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1389) Log API dependencies
 should be included automatically in deployments
Message-ID: <406082771.77119.1311346404298.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

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
             Fix For: 7.0.1.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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 10:55:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 22 Jul 2011 10:55:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-636) IronJacamar
	1.0.1.Final
In-Reply-To: <842374869.77093.1311346283717.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <409660387.77124.1311346523731.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-636.
-----------------------------------

    Resolution: Done


> IronJacamar 1.0.1.Final
> -----------------------
>
>                 Key: JBJCA-636
>                 URL: https://issues.jboss.org/browse/JBJCA-636
>             Project: IronJacamar
>          Issue Type: Release
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.1.Final
>
>
> Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&version=12317216

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 10:55:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 22 Jul 2011 10:55:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-635) Wrong classloader
 used for plugins
In-Reply-To: <503286272.76356.1311339818188.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <414268091.77127.1311346523815.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-635.
-----------------------------------

    Resolution: Done


> Wrong classloader used for plugins
> ----------------------------------
>
>                 Key: JBJCA-635
>                 URL: https://issues.jboss.org/browse/JBJCA-635
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 1.0.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.1.Final, 1.1.0.Alpha1
>
>
> The wrong classloader is used to load plugins for the JDBC resource adapter

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 10:55:23 2011
From: jira-events at lists.jboss.org (Gonne Martens (JIRA))
Date: Fri, 22 Jul 2011 10:55:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1390) NullPointerException
 in CMTTxInterceptor when invoking EJB3 bean
Message-ID: <944008552.77131.1311346523914.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

NullPointerException in CMTTxInterceptor when invoking EJB3 bean
----------------------------------------------------------------

                 Key: AS7-1390
                 URL: https://issues.jboss.org/browse/AS7-1390
             Project: Application Server 7
          Issue Type: Bug
          Components: EJB
    Affects Versions: 7.1.0.Alpha1
         Environment: Java 1.6.0_23 64bit, Windows 7 64bit 
            Reporter: Gonne Martens
            Assignee: Carlo de Wolf


A call to any EJB3 bean results in a NullPointerException.

{code}
15:04:08,888 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/JBoss7Playground].[de.mobileview.playground.TestServlet]] (http-127.0.0.1-127.0.0.1-8080-1) Servlet.service() for servlet de.mobileview.playground.TestServlet threw exception: java.lang.NullPointerException
	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:209)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:35)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
	at de.mobileview.playground.TestBean$$$view1.ping(Unknown Source) [classes:]
	at de.mobileview.playground.TestServlet.doGet(TestServlet.java:21) [classes:]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
	at java.lang.Thread.run(Unknown Source) [:1.6.0_23]
{code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 10:57:23 2011
From: jira-events at lists.jboss.org (Gonne Martens (JIRA))
Date: Fri, 22 Jul 2011 10:57:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1390) NullPointerException
 in CMTTxInterceptor when invoking EJB3 bean
In-Reply-To: <944008552.77131.1311346523914.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1893322260.77136.1311346643726.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gonne Martens updated AS7-1390:
-------------------------------

    Attachment: jboss7playground-0.0.1-SNAPSHOT.war
                jboss7playground-0.0.1-SNAPSHOT-sources.jar


Simple war with a EJB3 bean invoked by a servlet.

> NullPointerException in CMTTxInterceptor when invoking EJB3 bean
> ----------------------------------------------------------------
>
>                 Key: AS7-1390
>                 URL: https://issues.jboss.org/browse/AS7-1390
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 7.1.0.Alpha1
>         Environment: Java 1.6.0_23 64bit, Windows 7 64bit 
>            Reporter: Gonne Martens
>            Assignee: Carlo de Wolf
>         Attachments: jboss7playground-0.0.1-SNAPSHOT-sources.jar, jboss7playground-0.0.1-SNAPSHOT.war
>
>
> A call to any EJB3 bean results in a NullPointerException.
> {code}
> 15:04:08,888 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/JBoss7Playground].[de.mobileview.playground.TestServlet]] (http-127.0.0.1-127.0.0.1-8080-1) Servlet.service() for servlet de.mobileview.playground.TestServlet threw exception: java.lang.NullPointerException
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:209)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:35)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
> 	at de.mobileview.playground.TestBean$$$view1.ping(Unknown Source) [classes:]
> 	at de.mobileview.playground.TestServlet.doGet(TestServlet.java:21) [classes:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at java.lang.Thread.run(Unknown Source) [:1.6.0_23]
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 10:57:23 2011
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Fri, 22 Jul 2011 10:57:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1390) NullPointerException
 in CMTTxInterceptor when invoking EJB3 bean
In-Reply-To: <944008552.77131.1311346523914.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <984774504.77139.1311346643785.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

SBS JIRA Integration updated AS7-1390:
--------------------------------------

    Forum Reference: http://community.jboss.org/message/617019#617019  (was: http://community.jboss.org/message/617019#617019)


> NullPointerException in CMTTxInterceptor when invoking EJB3 bean
> ----------------------------------------------------------------
>
>                 Key: AS7-1390
>                 URL: https://issues.jboss.org/browse/AS7-1390
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 7.1.0.Alpha1
>         Environment: Java 1.6.0_23 64bit, Windows 7 64bit 
>            Reporter: Gonne Martens
>            Assignee: Carlo de Wolf
>         Attachments: jboss7playground-0.0.1-SNAPSHOT-sources.jar, jboss7playground-0.0.1-SNAPSHOT.war
>
>
> A call to any EJB3 bean results in a NullPointerException.
> {code}
> 15:04:08,888 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/JBoss7Playground].[de.mobileview.playground.TestServlet]] (http-127.0.0.1-127.0.0.1-8080-1) Servlet.service() for servlet de.mobileview.playground.TestServlet threw exception: java.lang.NullPointerException
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:209)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:35)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
> 	at de.mobileview.playground.TestBean$$$view1.ping(Unknown Source) [classes:]
> 	at de.mobileview.playground.TestServlet.doGet(TestServlet.java:21) [classes:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at java.lang.Thread.run(Unknown Source) [:1.6.0_23]
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 11:02:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 22 Jul 2011 11:02:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1389) Log API
 dependencies should be included automatically in deployments
In-Reply-To: <406082771.77119.1311346404298.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <289618916.77162.1311346943661.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615945#comment-12615945 ] 

jaikiran pai commented on AS7-1389:
-----------------------------------

Out of curiosity, why do we want to do that? Especially in cases where the users usually end up packaging these jars (either due to Maven or intentionally) within their .war/WEB-INF/lib or .ear/lib folders.

Adding these implicit dependencies will force them to have a jboss-deployment-structure.xml just to exclude these dependencies. On the other hand, I think if users want to rely on the version of these libraries shipped in AS, then I guess it would be better to just have them explicitly list it as a module dependency via jboss-deployment-structure.xml or MANIFEST.MF


> 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
>             Fix For: 7.0.1.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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 11:31:23 2011
From: jira-events at lists.jboss.org (Julio Faerman (JIRA))
Date: Fri, 22 Jul 2011 11:31:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-7447) PersistentManager
 for sessions is broken
In-Reply-To: <1521782221.1258250489836.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <252521704.77314.1311348683961.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBAS-7447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615960#comment-12615960 ] 

Julio Faerman commented on JBAS-7447:
-------------------------------------

How was this implemented? I need the exact same in EAP 5.1.1...

> PersistentManager for sessions is broken
> ----------------------------------------
>
>                 Key: JBAS-7447
>                 URL: https://issues.jboss.org/browse/JBAS-7447
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-5.1.0.GA
>            Reporter: Emilio Davis
>            Assignee: Remy Maucherat
>             Fix For: 6.0.0.M2
>
>
> Using the following context.xml
> <Context cookies="true" crossContext="true">
>    <Manager className="org.apache.catalina.session.PersistentManager" maxIdleSwap="1200" saveOnRestart="true">
>       <Store checkInterval="60" className="org.apache.catalina.session.JDBCStore" connectionURL="jdbc:mysql://localhost:3306/XXX?user=XXX&amp;password=XXX" driverName="com.mysql.jdbc.Driver" sessionAppCol="app_name" sessionDataCol="session_data" sessionIdCol="session_id" sessionLastAccessedCol="last_access" sessionMaxInactiveCol="max_inactive" sessionTable="tomcat_sessions" sessionValidCol="valid_session"/>
>    </Manager>
>    <InstanceListener>org.jboss.web.tomcat.security.RunAsListener</InstanceListener>
> </Context>
> That used to work in jboss4.0.5GA and correct according to tomcat 6 documentation jboss 5.1.0GA fails to start tomcat with the following exception:
> 2009-11-02 23:11:54,292 INFO  [org.jboss.web.tomcat.service.deployers.TomcatDeployment] (main) deplo
> y, ctxPath=/
> 2009-11-02 23:11:55,619 ERROR [org.jboss.web.tomcat.service.deployers.JBossContextConfig] (main) XML
>  error parsing: context.xml
> org.jboss.xb.binding.JBossXBException: Failed to parse source: Store not found as a child of Manager
>  in unordered_sequence: attributes?
>     at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:203)
>     at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:183)
>     at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:133)
>     at org.jboss.web.tomcat.service.deployers.JBossContextConfig.processContextConfig(JBossContextCo
> nfig.java:573)
>     at org.jboss.web.tomcat.service.deployers.JBossContextConfig.init(JBossContextConfig.java:536)
>     at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:279)
>     at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
>     at org.apache.catalina.core.StandardContext.init(StandardContext.java:5436)
>     at org.apache.catalina.core.StandardContext.start(StandardContext.java:4148)
>     at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeploymen
> t.java:310)
>     at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:1
> 42)
>     at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461)
>     at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118)
>     at org.jboss.web.deployers.WebModule.start(WebModule.java:97)
>     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.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
>     at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
>     at $Proxy38.start(Unknown Source)
> I opened a thread in the tomcat integration forum (http://www.jboss.org/index.html?module=bb&op=viewtopic&t=163337) but got no response.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 11:31:24 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 22 Jul 2011 11:31:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1389) Log API
 dependencies should be included automatically in deployments
In-Reply-To: <406082771.77119.1311346404298.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <214207743.77316.1311348684007.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615961#comment-12615961 ] 

David Lloyd commented on AS7-1389:
----------------------------------

99% of the time I think the user wants to have centrally configured logging, in which case the deployment should use our APIs and just ignore whatever is packaged with the application whether it was included intentionally or not.  As it is right now if people include logging JARs it's hard to say exactly what will happen - sometimes nothing is logged (for example if the slf4j API is bundled with no impl and the no-op logger is selected), sometimes the app will have separate logging (if it uses log4j and they bundle their own), sometimes it will use container logging (if they do not bundle anything, or if they include their own slf4j API but use Dependency: or another mechanism to get our impl).

I'd rather require that users include the JARs *and* specify the dependency exclusion if they want to do their own logging outside of the container.  Otherwise all logging should always go through the container just for consistency if nothing else.

> 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
>             Fix For: 7.0.1.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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 11:35:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 22 Jul 2011 11:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1286) IronJacamar
	1.0.1.Final
In-Reply-To: <603039307.53873.1310654185047.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1824694747.77320.1311348923626.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated AS7-1286:
---------------------------------

          Summary: IronJacamar 1.0.1.Final  (was: IronJacamar 1.0.0.Final)
    Fix Version/s: 7.0.1.Final
                       (was: 7.1.0.Alpha1)
         Priority: Critical  (was: Major)


> IronJacamar 1.0.1.Final
> -----------------------
>
>                 Key: AS7-1286
>                 URL: https://issues.jboss.org/browse/AS7-1286
>             Project: Application Server 7
>          Issue Type: Component  Upgrade
>          Components: Build System
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 7.0.1.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 11:48:23 2011
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 22 Jul 2011 11:48:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-3138)
 NullPointerException on RuleFlowGroupImpl after a rollback on a
 StatefulKnowledgeSession
In-Reply-To: <407506615.49638.1310518163610.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1752710981.77332.1311349703764.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBRULES-3138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli resolved JBRULES-3138.
------------------------------------

         Assignee: Edson Tirelli  (was: Mark Proctor)
    Fix Version/s: 5.2.1.Final
                   5.3.0.Beta1
       Resolution: Done


Thanks for providing fix and test case. Fix applied. 

> NullPointerException on RuleFlowGroupImpl after a rollback on a StatefulKnowledgeSession
> ----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3138
>                 URL: https://issues.jboss.org/browse/JBRULES-3138
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.2.0.Final
>            Reporter: Cristiano Nicolai
>            Assignee: Edson Tirelli
>             Fix For: 5.2.1.Final, 5.3.0.Beta1
>
>         Attachments: process-test.zip
>
>
> After executing some action that causes the StatefulKnowledgeSession to rollback, a NullPointerExption is throw on RuleFlowGroupImpl.setActive(RuleFlowGroupImpl.java:121) when it tries to use the workingMemory object. It seems that RuleFlowGroupImpl is not correctly deserialized/recreated after the rollback.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 11:48:23 2011
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 22 Jul 2011 11:48:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-3138)
 NullPointerException on RuleFlowGroupImpl after a rollback on a
 StatefulKnowledgeSession
In-Reply-To: <407506615.49638.1310518163610.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1614454725.77338.1311349703913.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBRULES-3138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-3138.
----------------------------------



> NullPointerException on RuleFlowGroupImpl after a rollback on a StatefulKnowledgeSession
> ----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3138
>                 URL: https://issues.jboss.org/browse/JBRULES-3138
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.2.0.Final
>            Reporter: Cristiano Nicolai
>            Assignee: Edson Tirelli
>             Fix For: 5.2.1.Final, 5.3.0.Beta1
>
>         Attachments: process-test.zip
>
>
> After executing some action that causes the StatefulKnowledgeSession to rollback, a NullPointerExption is throw on RuleFlowGroupImpl.setActive(RuleFlowGroupImpl.java:121) when it tries to use the workingMemory object. It seems that RuleFlowGroupImpl is not correctly deserialized/recreated after the rollback.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 11:50:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 22 Jul 2011 11:50:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1390) NullPointerException
 in CMTTxInterceptor when invoking EJB3 bean
In-Reply-To: <944008552.77131.1311346523914.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1478055053.77347.1311349823843.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf updated AS7-1390:
-------------------------------

    Affects Version/s:     (was: 7.1.0.Alpha1)
      Forum Reference: http://community.jboss.org/message/617019#617019  (was: http://community.jboss.org/message/617019#617019)


> NullPointerException in CMTTxInterceptor when invoking EJB3 bean
> ----------------------------------------------------------------
>
>                 Key: AS7-1390
>                 URL: https://issues.jboss.org/browse/AS7-1390
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>         Environment: Java 1.6.0_23 64bit, Windows 7 64bit 
>            Reporter: Gonne Martens
>            Assignee: Carlo de Wolf
>         Attachments: jboss7playground-0.0.1-SNAPSHOT-sources.jar, jboss7playground-0.0.1-SNAPSHOT.war
>
>
> A call to any EJB3 bean results in a NullPointerException.
> {code}
> 15:04:08,888 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/JBoss7Playground].[de.mobileview.playground.TestServlet]] (http-127.0.0.1-127.0.0.1-8080-1) Servlet.service() for servlet de.mobileview.playground.TestServlet threw exception: java.lang.NullPointerException
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:209)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:35)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
> 	at de.mobileview.playground.TestBean$$$view1.ping(Unknown Source) [classes:]
> 	at de.mobileview.playground.TestServlet.doGet(TestServlet.java:21) [classes:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at java.lang.Thread.run(Unknown Source) [:1.6.0_23]
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 12:50:23 2011
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 22 Jul 2011 12:50:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-3143) Knowledge Agent
 does not handle multiple packages in Builder output from single resource
In-Reply-To: <1469969996.55952.1310723183785.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1649605668.77510.1311353423851.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBRULES-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli resolved JBRULES-3143.
------------------------------------

         Assignee: Edson Tirelli  (was: Mark Proctor)
    Fix Version/s: 5.3.0.Beta1
       Resolution: Done


Thanks to dsotty for the test case and fix.

> Knowledge Agent does not handle multiple packages in Builder output from single resource
> ----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3143
>                 URL: https://issues.jboss.org/browse/JBRULES-3143
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions: 5.2.0.Final
>            Reporter: Wolfgang Laun
>            Assignee: Edson Tirelli
>            Priority: Blocker
>             Fix For: 5.2.1.Final, 5.3.0.Beta1
>
>
> Note: see also https://issues.jboss.org/browse/JBRULES-2940
> KnowledgeAgent with a ChecngeSet containing a single DRL:
>    package x
>    import y.Type
>    declare Type
>       @role(event)
>    end
>    //...rules etc.
> If this is passed to the builder, it'll return two KnowledgePackageImpl objects, one with name 'x' and another one with name 'y'. But the KA only takes the first package from the Collection of packages returned by the builder.
> =!=> KA must process all packages from the builder.
> =!=> Incremental kBase building requires diff-ing between old/new packages. This, then, must take into account that contribution to one package can come from several resource builds.
> =!=> The idea that the kBuilder should return packages with different names from a single DRL build is probably wrong. If a Drools package foo contains an import bar.Type, then this is still an asset in package foo and needs to be handled as a type reference in foo. Any annotation additions must be carried by that asset foo. (The *Java* package of the imported bar.Type remains of course bar.)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 12:50:23 2011
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Fri, 22 Jul 2011 12:50:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-3143) Knowledge Agent
 does not handle multiple packages in Builder output from single resource
In-Reply-To: <1469969996.55952.1310723183785.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <687417517.77511.1311353423894.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBRULES-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-3143.
----------------------------------



> Knowledge Agent does not handle multiple packages in Builder output from single resource
> ----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3143
>                 URL: https://issues.jboss.org/browse/JBRULES-3143
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions: 5.2.0.Final
>            Reporter: Wolfgang Laun
>            Assignee: Edson Tirelli
>            Priority: Blocker
>             Fix For: 5.2.1.Final, 5.3.0.Beta1
>
>
> Note: see also https://issues.jboss.org/browse/JBRULES-2940
> KnowledgeAgent with a ChecngeSet containing a single DRL:
>    package x
>    import y.Type
>    declare Type
>       @role(event)
>    end
>    //...rules etc.
> If this is passed to the builder, it'll return two KnowledgePackageImpl objects, one with name 'x' and another one with name 'y'. But the KA only takes the first package from the Collection of packages returned by the builder.
> =!=> KA must process all packages from the builder.
> =!=> Incremental kBase building requires diff-ing between old/new packages. This, then, must take into account that contribution to one package can come from several resource builds.
> =!=> The idea that the kBuilder should return packages with different names from a single DRL build is probably wrong. If a Drools package foo contains an import bar.Type, then this is still an asset in package foo and needs to be handled as a type reference in foo. Any annotation additions must be carried by that asset foo. (The *Java* package of the imported bar.Type remains of course bar.)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 12:55:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 22 Jul 2011 12:55:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1390)
 NullPointerException in CMTTxInterceptor when invoking EJB3 bean
In-Reply-To: <944008552.77131.1311346523914.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <835930169.77518.1311353723689.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615985#comment-12615985 ] 

Carlo de Wolf commented on AS7-1390:
------------------------------------

Not reproducible.

https://github.com/wolfc/jboss-as/tree/AS7-1390

> NullPointerException in CMTTxInterceptor when invoking EJB3 bean
> ----------------------------------------------------------------
>
>                 Key: AS7-1390
>                 URL: https://issues.jboss.org/browse/AS7-1390
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>         Environment: Java 1.6.0_23 64bit, Windows 7 64bit 
>            Reporter: Gonne Martens
>            Assignee: Carlo de Wolf
>         Attachments: jboss7playground-0.0.1-SNAPSHOT-sources.jar, jboss7playground-0.0.1-SNAPSHOT.war
>
>
> A call to any EJB3 bean results in a NullPointerException.
> {code}
> 15:04:08,888 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/JBoss7Playground].[de.mobileview.playground.TestServlet]] (http-127.0.0.1-127.0.0.1-8080-1) Servlet.service() for servlet de.mobileview.playground.TestServlet threw exception: java.lang.NullPointerException
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:209)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:35)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
> 	at de.mobileview.playground.TestBean$$$view1.ping(Unknown Source) [classes:]
> 	at de.mobileview.playground.TestServlet.doGet(TestServlet.java:21) [classes:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at java.lang.Thread.run(Unknown Source) [:1.6.0_23]
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 13:01:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 22 Jul 2011 13:01:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1390)
 NullPointerException in CMTTxInterceptor when invoking EJB3 bean
In-Reply-To: <944008552.77131.1311346523914.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1698021105.77527.1311354083675.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615987#comment-12615987 ] 

jaikiran pai commented on AS7-1390:
-----------------------------------

Attached deployment works fine for me too http://localhost:8080/jboss7playground-0.0.1-SNAPSHOT/TestServlet

> NullPointerException in CMTTxInterceptor when invoking EJB3 bean
> ----------------------------------------------------------------
>
>                 Key: AS7-1390
>                 URL: https://issues.jboss.org/browse/AS7-1390
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>         Environment: Java 1.6.0_23 64bit, Windows 7 64bit 
>            Reporter: Gonne Martens
>            Assignee: Carlo de Wolf
>         Attachments: jboss7playground-0.0.1-SNAPSHOT-sources.jar, jboss7playground-0.0.1-SNAPSHOT.war
>
>
> A call to any EJB3 bean results in a NullPointerException.
> {code}
> 15:04:08,888 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/JBoss7Playground].[de.mobileview.playground.TestServlet]] (http-127.0.0.1-127.0.0.1-8080-1) Servlet.service() for servlet de.mobileview.playground.TestServlet threw exception: java.lang.NullPointerException
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:209)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:35)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
> 	at de.mobileview.playground.TestBean$$$view1.ping(Unknown Source) [classes:]
> 	at de.mobileview.playground.TestServlet.doGet(TestServlet.java:21) [classes:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at java.lang.Thread.run(Unknown Source) [:1.6.0_23]
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 13:08:23 2011
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 22 Jul 2011 13:08:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1390) NullPointerException
 in CMTTxInterceptor when invoking EJB3 bean
In-Reply-To: <944008552.77131.1311346523914.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <868750464.77538.1311354503804.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf resolved AS7-1390.
--------------------------------

    Resolution: Cannot Reproduce Bug


> NullPointerException in CMTTxInterceptor when invoking EJB3 bean
> ----------------------------------------------------------------
>
>                 Key: AS7-1390
>                 URL: https://issues.jboss.org/browse/AS7-1390
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>         Environment: Java 1.6.0_23 64bit, Windows 7 64bit 
>            Reporter: Gonne Martens
>            Assignee: Carlo de Wolf
>         Attachments: jboss7playground-0.0.1-SNAPSHOT-sources.jar, jboss7playground-0.0.1-SNAPSHOT.war
>
>
> A call to any EJB3 bean results in a NullPointerException.
> {code}
> 15:04:08,888 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/JBoss7Playground].[de.mobileview.playground.TestServlet]] (http-127.0.0.1-127.0.0.1-8080-1) Servlet.service() for servlet de.mobileview.playground.TestServlet threw exception: java.lang.NullPointerException
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:209)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:35)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
> 	at de.mobileview.playground.TestBean$$$view1.ping(Unknown Source) [classes:]
> 	at de.mobileview.playground.TestServlet.doGet(TestServlet.java:21) [classes:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at java.lang.Thread.run(Unknown Source) [:1.6.0_23]
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 13:41:23 2011
From: jira-events at lists.jboss.org (Anil Saldhana (JIRA))
Date: Fri, 22 Jul 2011 13:41:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1298) JBoss AS 7 doesn't
 appear to support container-managed security via web.xml and jboss-web.xml
In-Reply-To: <317987564.57015.1310743223751.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1881333813.77633.1311356483757.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anil Saldhana reassigned AS7-1298:
----------------------------------

    Assignee: Marcus Moyses  (was: Darran Lofthouse)


Marcus,  please add this task to the documentation task I have given you for AS7.

> JBoss AS 7 doesn't appear to support container-managed security via web.xml and jboss-web.xml
> ---------------------------------------------------------------------------------------------
>
>                 Key: AS7-1298
>                 URL: https://issues.jboss.org/browse/AS7-1298
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: EJB, Security, Web
>    Affects Versions: 7.0.0.Final
>         Environment: n/a
>            Reporter: Craig Ringer
>            Assignee: Marcus Moyses
>
> There's no documentation for container-managed security in JBoss AS 7, and the schema for the main jboss config files and jboss-web.xml don't suggest any configuration mechanisms for JAAS realms, principal-to-user/group mappings, etc.
> This is a significant limitation for apps porting from Glassfish 3, which expect to be able to access the current security principal from JNDI or inject it, and expect to be able to declare container-controlled access to particular URLs and different HTTP methods in web.xml.
> Documenting this limitation in AS 7.0.0 would be a big improvement and would save porting time and hassle. Implementing support in a future version would, of course, be ideal.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 14:06:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 22 Jul 2011 14:06:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1274) consecutive add of
 deployment does not fail/warn
In-Reply-To: <1971864514.51501.1310586623702.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1823145851.77653.1311357983681.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616005#comment-12616005 ] 

Brian Stansberry commented on AS7-1274:
---------------------------------------

This should be resolved, correct?

> consecutive add of deployment does not fail/warn 
> -------------------------------------------------
>
>                 Key: AS7-1274
>                 URL: https://issues.jboss.org/browse/AS7-1274
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.0.0.Final
>            Reporter: Max Rydahl Andersen
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>             Fix For: 7.0.1.Final
>
>
> using the scripts from https://github.com/maxandersen/as7scripting which simply just add contents and deploys it the following runs never fails.
> from discussion on irc it should.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 14:08:29 2011
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Fri, 22 Jul 2011 14:08:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1274) consecutive add of
 deployment does not fail/warn
In-Reply-To: <1971864514.51501.1310586623702.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <962660554.77657.1311358109025.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber resolved AS7-1274.
--------------------------------------

    Resolution: Done


> consecutive add of deployment does not fail/warn 
> -------------------------------------------------
>
>                 Key: AS7-1274
>                 URL: https://issues.jboss.org/browse/AS7-1274
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.0.0.Final
>            Reporter: Max Rydahl Andersen
>            Assignee: Emanuel Muckenhuber
>            Priority: Critical
>             Fix For: 7.0.1.Final
>
>
> using the scripts from https://github.com/maxandersen/as7scripting which simply just add contents and deploys it the following runs never fails.
> from discussion on irc it should.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 15:02:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Fri, 22 Jul 2011 15:02:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1348) RichFaces 4
 application fails with ELException
In-Reply-To: <961263785.68524.1311160163613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <606476341.77715.1311361343654.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616016#comment-12616016 ] 

Juergen Zimmermann commented on AS7-1348:
-----------------------------------------

Thank you! Your workaround works. So what's the conclusion? Is it a regression? I would say: yes. But of which component? Perhaps in RichFaces they could take care of it, when they implement tags like <rich:graphValidator ... groups="my.package.MyGroup">. Should I open an issue in their project?

> RichFaces 4 application fails with ELException
> ----------------------------------------------
>
>                 Key: AS7-1348
>                 URL: https://issues.jboss.org/browse/AS7-1348
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 7.0.0.Final
>         Environment: Jenkins build 1402
>            Reporter: Juergen Zimmermann
>         Attachments: testcase-src.zip, testcase.ear.zip
>
>
> I'm migrating an EAR from JBoss 6 to 7. The Web module is based on RichFaces 4 and Weld. However, I'm getting the stacktrace below. I'll attach a testcase.
> Stacktrace:
> javax.el.ELException: Cannot convert testcase.PasswordGroup of type class java.lang.String to class [Ljava.lang.Class;
> 	at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:470)
> 	at org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:46)
> 	at org.jboss.weld.util.el.ForwardingExpressionFactory.coerceToType(ForwardingExpressionFactory.java:37)
> 	at com.sun.faces.facelets.tag.BeanPropertyTagRule$LiteralPropertyMetadata.applyMetadata(BeanPropertyTagRule.java:88)
> 	at com.sun.faces.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:81)
> 	at javax.faces.view.facelets.MetaTagHandler.setAttributes(MetaTagHandler.java:129)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.setAttributes(DelegatingMetaTagHandler.java:102)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.setAttributes(BehaviorsAddingComponentHandlerWrapper.java:115)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.doNewComponentActions(ComponentTagHandlerDelegateImpl.java:402)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:159)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
> 	at org.richfaces.view.facelets.html.BehaviorsAddingComponentHandlerWrapper.applyNextHandler(BehaviorsAddingComponentHandlerWrapper.java:55)
> 	at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:184)
> 	at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
> 	at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:98)
> 	at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:82)
> 	at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:152)
> 	at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:744)
> 	at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:100)
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> 	at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:313)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:893)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:662)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 15:36:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 22 Jul 2011 15:36:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1299) Interface
 resource's criteria attribute should be read-write
In-Reply-To: <1146112164.57020.1310743291902.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1334398034.77724.1311363383631.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616019#comment-12616019 ] 

Brian Stansberry commented on AS7-1299:
---------------------------------------

Some details.

First, an update may or may not be immediately applicable to the runtime. If not, the model should be updated and context.reloadRequired() invoked.

The simplest way to determine whether reload is required is to check whether the MSC service behind the interface is State.UP. It's an on-demand service,  The service that should demand an interface, the SocketBinding, is also on-demand, so the interface service shouldn't be started unless something needs it.

Second, the value for the criteria attribute is a complex dmr structure; potentially very complex. So, while adding a write-attribute handler for this attribute is necessary, by itself it's not highly user friendly. More user friendly is to add operations to handle the most common use cases; the handlers for those would behind the scenes create the appropriate dmr node representing the criteria.

Common use cases:

1) <inet-address value="..."/>
2) <any-address/>
3) <any-ipv4-address/>
4) <any-ipv6-address/>
5) <loopback/>
6) <loopback address="127.0.0.2"/>

I thought about whether those could just be handled via quasi-runtime-attributes, read via read-attribute and set via write-attribute. But I don't think the semantic could be made clean/consistent with other attributes. Perhaps <any-[ipvX-]address/> and <loopback/> could be if the description made it clear that, e.g. :read-attribute(name=loopback) would only return true if the criteria was <loopback/>, not if it was <inet-address value="127-0.0.1"/>. Otherwise knowing whether to return true or false would require starting the service and resolving the criteria.

Alternatives:

1) :set-inet-address(value=10.0.0.1)
2) :set-any-address
3) :set-any-ipv4-address
4) :set-any-ipv6-address
5) :set-loopback
6) :set-loopback(address="127.0.0.2")

I'm not thrilled with using "set" in the operation names; we've discussed elsewhere using "read" and "write" in the API. Using "write" in those names reads funny though.

Another alternative:

1) write-criteria(inet-address=10.0.0.1)
2) write-criteria(any-address=true)
3) write-criteria(any-ipv4-address=true)
4) write-criteria(any-ipv6-address=true)
5) write-criteria(loopback=true)
6) write-criteria(loopback=true,inet-address=127.0.0.2)



> Interface resource's criteria attribute should be read-write 
> -------------------------------------------------------------
>
>                 Key: AS7-1299
>                 URL: https://issues.jboss.org/browse/AS7-1299
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.0.0.Final
>            Reporter: Brian Stansberry
>             Fix For: 7.1.0.Alpha1
>
>
> http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/003123.html

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 15:38:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 22 Jul 2011 15:38:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1299) Interface resource's
 criteria attribute should be read-write
In-Reply-To: <1146112164.57020.1310743291902.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <477176555.77730.1311363503797.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated AS7-1299:
----------------------------------

         Assignee: Emanuel Muckenhuber
    Fix Version/s: 7.0.1.Final
                       (was: 7.1.0.Alpha1)


> Interface resource's criteria attribute should be read-write 
> -------------------------------------------------------------
>
>                 Key: AS7-1299
>                 URL: https://issues.jboss.org/browse/AS7-1299
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 7.0.1.Final
>
>
> http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/003123.html

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 15:47:23 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Fri, 22 Jul 2011 15:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1299) Interface
 resource's criteria attribute should be read-write
In-Reply-To: <1146112164.57020.1310743291902.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <167026915.77739.1311364043770.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616020#comment-12616020 ] 

Heiko Rupp commented on AS7-1299:
---------------------------------

I would be fine with write-criteria or even a complex set of write-attribute.
The killer here is the current (arbitrary) nesting of stuff to describe an interface; that should just be a flat list of key-values like you described above. I don't mind the name of the operation that much.

> Interface resource's criteria attribute should be read-write 
> -------------------------------------------------------------
>
>                 Key: AS7-1299
>                 URL: https://issues.jboss.org/browse/AS7-1299
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 7.0.1.Final
>
>
> http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/003123.html

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 15:55:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 22 Jul 2011 15:55:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1298) JBoss AS 7 doesn't
 appear to support container-managed security via web.xml and jboss-web.xml
In-Reply-To: <317987564.57015.1310743223751.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <796705270.77750.1311364523747.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned AS7-1298:
-------------------------------------

    Assignee: Darran Lofthouse  (was: Marcus Moyses)


> JBoss AS 7 doesn't appear to support container-managed security via web.xml and jboss-web.xml
> ---------------------------------------------------------------------------------------------
>
>                 Key: AS7-1298
>                 URL: https://issues.jboss.org/browse/AS7-1298
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: EJB, Security, Web
>    Affects Versions: 7.0.0.Final
>         Environment: n/a
>            Reporter: Craig Ringer
>            Assignee: Darran Lofthouse
>
> There's no documentation for container-managed security in JBoss AS 7, and the schema for the main jboss config files and jboss-web.xml don't suggest any configuration mechanisms for JAAS realms, principal-to-user/group mappings, etc.
> This is a significant limitation for apps porting from Glassfish 3, which expect to be able to access the current security principal from JNDI or inject it, and expect to be able to declare container-controlled access to particular URLs and different HTTP methods in web.xml.
> Documenting this limitation in AS 7.0.0 would be a big improvement and would save porting time and hassle. Implementing support in a future version would, of course, be ideal.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 17:00:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 22 Jul 2011 17:00:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1299) Interface
 resource's criteria attribute should be read-write
In-Reply-To: <1146112164.57020.1310743291902.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <300877107.77818.1311368423726.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616033#comment-12616033 ] 

Brian Stansberry commented on AS7-1299:
---------------------------------------

If it was flattened out, it could just be a bunch of attributes, each accessible via the normal read-attribute and write-attribute. The "add" operation handler could take each attribute as a param. 

The nesting comes from the <not> and <any>. The <not/> could be flattened out with attributes named "not-inet-address" "not-point-to-point" etc. I suppose the same could be done with "any", e.g ."any-inet-address=10.0.0.5", "any-point-to-point" etc. Those attribute names are not very intuitive but TBH I doubt <any/> will be used much.

Emanuel, give some thought to doing it like that; see if there are any gotchas. 

Also, I don't think doing it that way would be incompatible with keeping a "criteria" attribute for backward compatibility.



> Interface resource's criteria attribute should be read-write 
> -------------------------------------------------------------
>
>                 Key: AS7-1299
>                 URL: https://issues.jboss.org/browse/AS7-1299
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 7.0.1.Final
>
>
> http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/003123.html

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 17:17:23 2011
From: jira-events at lists.jboss.org (Robert Baty (JIRA))
Date: Fri, 22 Jul 2011 17:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBWEB-206) New JSESSIONID for
 every request in JBossAS7 causing no sticky HttpSession
Message-ID: <1516349975.77845.1311369443628.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

New JSESSIONID for every request in JBossAS7 causing no sticky HttpSession
--------------------------------------------------------------------------

                 Key: JBWEB-206
                 URL: https://issues.jboss.org/browse/JBWEB-206
             Project: JBoss Web
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossWeb-7.0.0.CR4
         Environment: JBossAS 7.0.0.Final server running on a Windows 7 desktop with Oracle/Sun JDK 1.6.0_26.  Issue is occurring with Firefox 5, IE9 and IE8 browsers.
            Reporter: Robert Baty
            Assignee: Remy Maucherat


Deploying a JEE application to JBossAS7 when trying to get HttpSession data using request.getSession() a new session is created each time an no data is persisted.  Tracking this down I seem to be seeing a 
Set-Cookie  JSESSIONID=nTokSr2GnHgUTPZnbMtpgjfS; Version=1; Path="/rjb"
in every response with no Cookie being maintained for the next request.

I have tried this on a number of browsers.  It seems to be happening in Firefox 5 and Internet Explorer 8, 9.  I do seem to work with an older Firefox 3.6 browser however.

After thinking I have something wrong with my browser I deployed the application to JBossAS6 and used the same Firefox 5 browser and am seeing the JSESSIONID being established and session data being maintained between pages in memory.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 20:00:23 2011
From: jira-events at lists.jboss.org (sreeram vadlamudi (JIRA))
Date: Fri, 22 Jul 2011 20:00:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3151) jaxb generated
 fact loaded into Guvnor throws errors when using the ' is contained in the
 comma separated list' operator
Message-ID: <1099093938.78038.1311379223708.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

jaxb generated fact loaded into Guvnor throws errors when using the ' is contained in the comma separated list' operator
------------------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-3151
                 URL: https://issues.jboss.org/browse/JBRULES-3151
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.2.0.CR1
         Environment: weblogic 10.3.3 and windows XP
            Reporter: sreeram vadlamudi
            Assignee: Mark Proctor


I have a jaxb generated class loaded through the model jar into Guvnor to be used as a fact in the Guided Decision Table editor.
 
When I use a field ACTIVITYCODE  of type String from the JAXB generated class  with 'is contained in the comma separated list'  operator, I get compilation errors. 
 
Unable to Analyse Expression ACTIVITYCODE == "A" || ACTIVITYCODE == "B": [Error: no such identifier: ACTIVITYCODE] [Near : {... ACTIVITYCODE == "A" || ACTIVI ....}] ^ [Line: 1, Column: 1]
 
But when I use equal to operator to compare value to just a string value, it compiles fine. 


3.      |       rule "Row 1 dds"
4.      |           ruleflow-group "None"
5.      |           dialect "mvel"
6.      |           when
7.      |               factClass : FACTCLASS( ACTIVITYCODE in ("A", "B"))
8.      |           then
9.      |               factClass.setRATE( "5.25" );
10.     |       end
 
The below rule compiles fine.
 
 
3.      |       rule "Row 1 dds"
4.      |           ruleflow-group "None"
5.      |           dialect "mvel"
6.      |           when
7.      |               factClass : FACTCLASS ( ACTIVITYCODE =="A") 
8.      |           then
9.      |               factClass.setRATE( "5.25" );
10.     |       end




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 22 22:56:23 2011
From: jira-events at lists.jboss.org (Abhijit Sarkar (JIRA))
Date: Fri, 22 Jul 2011 22:56:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1360) Incorrect
 soap:address connector port generated in WSDL for JAX-WS service
In-Reply-To: <1522203522.72363.1311252083923.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1690314360.78048.1311389783674.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616049#comment-12616049 ] 

Abhijit Sarkar commented on AS7-1360:
-------------------------------------

This is making any Web Service useless on an AS instance that is not running on default port. Doesn't this qualify for a fix?

> Incorrect soap:address connector port generated in WSDL for JAX-WS service
> --------------------------------------------------------------------------
>
>                 Key: AS7-1360
>                 URL: https://issues.jboss.org/browse/AS7-1360
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>         Environment: Ubuntu 11.04, JBoss AS 7.0.0.Final
>            Reporter: Abhijit Sarkar
>            Assignee: Jim Ma
>
> Default soap:address connector port generated in WSDL even though server is running on a different HTTP port. Please see forum reference for detail.
> ??
> jaikiran pai wrote:
> Please open a JIRA for this. The way the connector port is being inferred from the configured connectors, from the JBoss WS code, will not work in AS7.
> ??

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 23 03:57:23 2011
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Sat, 23 Jul 2011 03:57:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1360) Incorrect
 soap:address connector port generated in WSDL for JAX-WS service
In-Reply-To: <1522203522.72363.1311252083923.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2010522144.78080.1311407843910.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616050#comment-12616050 ] 

Alessio Soldano commented on AS7-1360:
--------------------------------------

If it is confirmed, sure it does. I've assigned it to Jim, who is likely having a look very soon. Now also scheduling for the first coming release (while this might also be an AS7 only fix, resulting in this jira being moved to the AS7 area, we'll see).

> Incorrect soap:address connector port generated in WSDL for JAX-WS service
> --------------------------------------------------------------------------
>
>                 Key: AS7-1360
>                 URL: https://issues.jboss.org/browse/AS7-1360
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>         Environment: Ubuntu 11.04, JBoss AS 7.0.0.Final
>            Reporter: Abhijit Sarkar
>            Assignee: Jim Ma
>             Fix For: 7.0.1.Final
>
>
> Default soap:address connector port generated in WSDL even though server is running on a different HTTP port. Please see forum reference for detail.
> ??
> jaikiran pai wrote:
> Please open a JIRA for this. The way the connector port is being inferred from the configured connectors, from the JBoss WS code, will not work in AS7.
> ??

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 23 03:57:24 2011
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Sat, 23 Jul 2011 03:57:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1360) Incorrect
 soap:address connector port generated in WSDL for JAX-WS service
In-Reply-To: <1522203522.72363.1311252083923.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <88697399.78088.1311407844136.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano updated AS7-1360:
---------------------------------

      Fix Version/s: 7.0.1.Final
    Forum Reference: http://community.jboss.org/message/616633#616633  (was: http://community.jboss.org/message/616633#616633)


> Incorrect soap:address connector port generated in WSDL for JAX-WS service
> --------------------------------------------------------------------------
>
>                 Key: AS7-1360
>                 URL: https://issues.jboss.org/browse/AS7-1360
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>         Environment: Ubuntu 11.04, JBoss AS 7.0.0.Final
>            Reporter: Abhijit Sarkar
>            Assignee: Jim Ma
>             Fix For: 7.0.1.Final
>
>
> Default soap:address connector port generated in WSDL even though server is running on a different HTTP port. Please see forum reference for detail.
> ??
> jaikiran pai wrote:
> Please open a JIRA for this. The way the connector port is being inferred from the configured connectors, from the JBoss WS code, will not work in AS7.
> ??

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 23 03:57:24 2011
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Sat, 23 Jul 2011 03:57:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-1360)
 Incorrect soap:address connector port generated in WSDL for JAX-WS service
In-Reply-To: <1522203522.72363.1311252083923.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2061889069.78091.1311407844208.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616050#comment-12616050 ] 

Alessio Soldano edited comment on AS7-1360 at 7/23/11 3:56 AM:
---------------------------------------------------------------

If it is confirmed, sure it does. I've assigned it to Jim, who is likely having a look very soon. Now also scheduling for the first coming release (while this might also be an JBWS only fix, resulting in this jira being moved to the JBWS area, we'll see).

      was (Author: asoldano):
    If it is confirmed, sure it does. I've assigned it to Jim, who is likely having a look very soon. Now also scheduling for the first coming release (while this might also be an AS7 only fix, resulting in this jira being moved to the AS7 area, we'll see).
  
> Incorrect soap:address connector port generated in WSDL for JAX-WS service
> --------------------------------------------------------------------------
>
>                 Key: AS7-1360
>                 URL: https://issues.jboss.org/browse/AS7-1360
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>         Environment: Ubuntu 11.04, JBoss AS 7.0.0.Final
>            Reporter: Abhijit Sarkar
>            Assignee: Jim Ma
>             Fix For: 7.0.1.Final
>
>
> Default soap:address connector port generated in WSDL even though server is running on a different HTTP port. Please see forum reference for detail.
> ??
> jaikiran pai wrote:
> Please open a JIRA for this. The way the connector port is being inferred from the configured connectors, from the JBoss WS code, will not work in AS7.
> ??

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 23 10:05:23 2011
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Sat, 23 Jul 2011 10:05:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBRULES-3143) Knowledge Agent
 does not handle multiple packages in Builder output from single resource
In-Reply-To: <1469969996.55952.1310723183785.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1754480968.78125.1311429923776.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBRULES-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wolfgang Laun reopened JBRULES-3143:
------------------------------------



A NPE occurs when the DRL package differs from the one from which a class (used in a declare) is imported.

package hashcode ### package hashcode.foo
import hashcode.SimpleType
declare SimpleType
@role(event)
end

kaConf.setProperty("drools.agent.newInstance", "false");

Exception in thread "main" java.lang.NullPointerException
	at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:56)
	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:80)
	at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:65)
	at org.drools.common.NamedEntryPoint.createHandle(NamedEntryPoint.java:705)
	at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:282)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:905)
	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:864)
	at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:255)


> Knowledge Agent does not handle multiple packages in Builder output from single resource
> ----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3143
>                 URL: https://issues.jboss.org/browse/JBRULES-3143
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions: 5.2.0.Final
>            Reporter: Wolfgang Laun
>            Assignee: Edson Tirelli
>            Priority: Blocker
>             Fix For: 5.2.1.Final, 5.3.0.Beta1
>
>
> Note: see also https://issues.jboss.org/browse/JBRULES-2940
> KnowledgeAgent with a ChecngeSet containing a single DRL:
>    package x
>    import y.Type
>    declare Type
>       @role(event)
>    end
>    //...rules etc.
> If this is passed to the builder, it'll return two KnowledgePackageImpl objects, one with name 'x' and another one with name 'y'. But the KA only takes the first package from the Collection of packages returned by the builder.
> =!=> KA must process all packages from the builder.
> =!=> Incremental kBase building requires diff-ing between old/new packages. This, then, must take into account that contribution to one package can come from several resource builds.
> =!=> The idea that the kBuilder should return packages with different names from a single DRL build is probably wrong. If a Drools package foo contains an import bar.Type, then this is still an asset in package foo and needs to be handled as a type reference in foo. Any annotation additions must be carried by that asset foo. (The *Java* package of the imported bar.Type remains of course bar.)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 23 13:54:23 2011
From: jira-events at lists.jboss.org (Scott Kroll (JIRA))
Date: Sat, 23 Jul 2011 13:54:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1391)
 org.apache.commons.beanutils module should depend on
 org.apache.commons.collections
Message-ID: <1717391375.78170.1311443663630.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

org.apache.commons.beanutils module should depend on org.apache.commons.collections
-----------------------------------------------------------------------------------

                 Key: AS7-1391
                 URL: https://issues.jboss.org/browse/AS7-1391
             Project: Application Server 7
          Issue Type: Bug
          Components: Modules
    Affects Versions: 7.0.0.Final
            Reporter: Scott Kroll
            Assignee: David Lloyd


When deploying a project that depends on the org.commons.beanutils project, the classloader for the org.commons.beanutils module throws an exception:

java.lang.ClassNotFoundException:org.apache.commons.collections.Transformer from [Module "org.apache.commons.beanutils:main" from local module loader @6ef137d

After adding the org.commons.collections dependency to the org.commons.beanutils module, this is resolved.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 23 15:25:23 2011
From: jira-events at lists.jboss.org (Gonne Martens (JIRA))
Date: Sat, 23 Jul 2011 15:25:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-1390) NullPointerException
 in CMTTxInterceptor when invoking EJB3 bean
In-Reply-To: <944008552.77131.1311346523914.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1522500647.78174.1311449123681.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gonne Martens closed AS7-1390.
------------------------------



> NullPointerException in CMTTxInterceptor when invoking EJB3 bean
> ----------------------------------------------------------------
>
>                 Key: AS7-1390
>                 URL: https://issues.jboss.org/browse/AS7-1390
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>         Environment: Java 1.6.0_23 64bit, Windows 7 64bit 
>            Reporter: Gonne Martens
>            Assignee: Carlo de Wolf
>         Attachments: jboss7playground-0.0.1-SNAPSHOT-sources.jar, jboss7playground-0.0.1-SNAPSHOT.war
>
>
> A call to any EJB3 bean results in a NullPointerException.
> {code}
> 15:04:08,888 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/JBoss7Playground].[de.mobileview.playground.TestServlet]] (http-127.0.0.1-127.0.0.1-8080-1) Servlet.service() for servlet de.mobileview.playground.TestServlet threw exception: java.lang.NullPointerException
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:209)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:35)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
> 	at de.mobileview.playground.TestBean$$$view1.ping(Unknown Source) [classes:]
> 	at de.mobileview.playground.TestServlet.doGet(TestServlet.java:21) [classes:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at java.lang.Thread.run(Unknown Source) [:1.6.0_23]
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 23 15:39:23 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Sat, 23 Jul 2011 15:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1392) Description in
 scripts to secure the api wrong
Message-ID: <282609395.78179.1311449963606.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Description in scripts to secure the api wrong
----------------------------------------------

                 Key: AS7-1392
                 URL: https://issues.jboss.org/browse/AS7-1392
             Project: Application Server 7
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 7.0.0.Final
            Reporter: Heiko Rupp
            Assignee: Brian Stansberry


Script says to execute 

snert:~/downloads/jboss-as-web-7.0.0.Final hrupp$ bin/jboss-admin.sh -c --file=scripts/secure-standalone-mgmt.cli
File /Users/hrupp/Downloads/jboss-as-web-7.0.0.Final/scripts/secure-standalone-mgmt.cli doesn't exist.

which fails.

Also the description in the file fails to mention that the server must be started for this (or alternatively to start the server, but as it a cli script, this is probably not expected).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 23 15:44:23 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Sat, 23 Jul 2011 15:44:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1392) Description in
 scripts to secure the api wrong
In-Reply-To: <282609395.78179.1311449963606.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <978818652.78184.1311450263637.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616057#comment-12616057 ] 

Heiko Rupp commented on AS7-1392:
---------------------------------

Patch is in https://github.com/pilhuhn/jboss-as/commit/2d72a1ee5ea9a93ec2e8482a6a0174c1f510b3c3

> Description in scripts to secure the api wrong
> ----------------------------------------------
>
>                 Key: AS7-1392
>                 URL: https://issues.jboss.org/browse/AS7-1392
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.0.0.Final
>            Reporter: Heiko Rupp
>            Assignee: Brian Stansberry
>
> Script says to execute 
> snert:~/downloads/jboss-as-web-7.0.0.Final hrupp$ bin/jboss-admin.sh -c --file=scripts/secure-standalone-mgmt.cli
> File /Users/hrupp/Downloads/jboss-as-web-7.0.0.Final/scripts/secure-standalone-mgmt.cli doesn't exist.
> which fails.
> Also the description in the file fails to mention that the server must be started for this (or alternatively to start the server, but as it a cli script, this is probably not expected).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 23 20:17:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Sat, 23 Jul 2011 20:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1393) Make Infinispan
 default 2nd level cache provider for hibernate
Message-ID: <700789921.78223.1311466643701.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Make Infinispan default 2nd level cache provider for hibernate
--------------------------------------------------------------

                 Key: AS7-1393
                 URL: https://issues.jboss.org/browse/AS7-1393
             Project: Application Server 7
          Issue Type: Enhancement
          Components: JPA / Hibernate
    Affects Versions: 7.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Scott Marlow
             Fix For: 7.0.1.Final, 7.1.0.Alpha1


I thought this was the already the case, but apparently it isn't yet.
Users should not need to specify a value for hibernate.cache.region.factory_class in their persistence.xml.
If undefined, the jpa subsystem should default the hibernate.cache.region.factory_class to "org.hibernate.cache.infinispan.JndiInfinispanRegionFactory".  Likewise, the requisite hibernate.cache.infinispan.cachemanager property should default to "java:jboss/infinispan/hibernate".

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 23 21:31:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Sat, 23 Jul 2011 21:31:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1393) Make Infinispan
 default 2nd level cache provider for hibernate
In-Reply-To: <700789921.78223.1311466643701.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1754841371.78238.1311471083667.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616063#comment-12616063 ] 

Scott Marlow commented on AS7-1393:
-----------------------------------

Can you be more specific as to what problem this is causing?

Currently, if the user sets property "hibernate.cache.infinispan.cachemanager", we add a dependency on the specified value (in which case the cache manager will be started).  If an application isn't using a 2lc, they wouldn't set this property (which means the cache isn't started).  I don't think that we want the Infinispan cache to be started by default.

> Make Infinispan default 2nd level cache provider for hibernate
> --------------------------------------------------------------
>
>                 Key: AS7-1393
>                 URL: https://issues.jboss.org/browse/AS7-1393
>             Project: Application Server 7
>          Issue Type: Enhancement
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Scott Marlow
>             Fix For: 7.0.1.Final, 7.1.0.Alpha1
>
>
> I thought this was the already the case, but apparently it isn't yet.
> Users should not need to specify a value for hibernate.cache.region.factory_class in their persistence.xml.
> If undefined, the jpa subsystem should default the hibernate.cache.region.factory_class to "org.hibernate.cache.infinispan.JndiInfinispanRegionFactory".  Likewise, the requisite hibernate.cache.infinispan.cachemanager property should default to "java:jboss/infinispan/hibernate".

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 23 23:10:29 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Sat, 23 Jul 2011 23:10:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1393) Make Infinispan
 default 2nd level cache provider for hibernate
In-Reply-To: <700789921.78223.1311466643701.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1294818252.78250.1311477029716.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616064#comment-12616064 ] 

Scott Marlow commented on AS7-1393:
-----------------------------------

If there isn't a bigger underlying problem that your trying to solve.  It looks like we can check if "hibernate.cache.infinispan.cachemanager" is set and then default the "hibernate.cache.region.factory_class" property to "org.hibernate.cache.infinispan.JndiInfinispanRegionFactory" (if its not already set).  That seems easy to do.

There is probably more that we can do (depending on the underlying provider, we could check shared-cache-mode), but I'd like to understand what pain this is causing (if any).

> Make Infinispan default 2nd level cache provider for hibernate
> --------------------------------------------------------------
>
>                 Key: AS7-1393
>                 URL: https://issues.jboss.org/browse/AS7-1393
>             Project: Application Server 7
>          Issue Type: Enhancement
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Scott Marlow
>             Fix For: 7.0.1.Final, 7.1.0.Alpha1
>
>
> I thought this was the already the case, but apparently it isn't yet.
> Users should not need to specify a value for hibernate.cache.region.factory_class in their persistence.xml.
> If undefined, the jpa subsystem should default the hibernate.cache.region.factory_class to "org.hibernate.cache.infinispan.JndiInfinispanRegionFactory".  Likewise, the requisite hibernate.cache.infinispan.cachemanager property should default to "java:jboss/infinispan/hibernate".

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 24 08:12:23 2011
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Sun, 24 Jul 2011 08:12:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBDEPLOY-277) Fix declarative
 structure to handle .war files explicitly
Message-ID: <1832906309.78292.1311509543630.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Fix declarative structure to handle .war files explicitly
---------------------------------------------------------

                 Key: JBDEPLOY-277
                 URL: https://issues.jboss.org/browse/JBDEPLOY-277
             Project: JBoss Deployers
          Issue Type: Task
          Components: structure
    Affects Versions: JBDEPLOY-2.2.1.GA
            Reporter: Ales Justin
            Assignee: Ales Justin
             Fix For: JBDEPLOY-2.2.2.GA


See JBAS-8786 for more details.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 24 08:14:23 2011
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Sun, 24 Jul 2011 08:14:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBDEPLOY-276) End of file new
 line in aliases.txt creates empty alias
In-Reply-To: <2045543350.47471.1310454383643.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <455771824.78299.1311509663861.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBDEPLOY-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin reassigned JBDEPLOY-276:
------------------------------------

    Assignee: Ales Justin


> End of file new line in aliases.txt creates empty alias
> -------------------------------------------------------
>
>                 Key: JBDEPLOY-276
>                 URL: https://issues.jboss.org/browse/JBDEPLOY-276
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: vfs
>    Affects Versions: JBDEPLOY-2.2.1.GA
>            Reporter: Pontus Ullgren
>            Assignee: Ales Justin
>            Priority: Minor
>         Attachments: JBDEPLOY-276.diff.gz
>
>
> A empty line in aliases.txt will result in a alias without name being created.
> This becomes obvious when two modules happens to have a empty new line in the end of the aliases.txt file the result is then 
> Caused by: java.lang.IllegalStateException: 
> _Alias_AbstractKernelController[29048474] is already installed.
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
> My suggestion is to simply filter out any empty line in org.jboss.deployers.vfs.plugins.dependency.AliasesParserDeployer#parse(...).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 24 08:24:23 2011
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Sun, 24 Jul 2011 08:24:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-276) End of file new
 line in aliases.txt creates empty alias
In-Reply-To: <2045543350.47471.1310454383643.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2082561390.78303.1311510263741.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBDEPLOY-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin resolved JBDEPLOY-276.
----------------------------------

    Fix Version/s: JBDEPLOY-2.2.2.GA
       Resolution: Done


> End of file new line in aliases.txt creates empty alias
> -------------------------------------------------------
>
>                 Key: JBDEPLOY-276
>                 URL: https://issues.jboss.org/browse/JBDEPLOY-276
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: vfs
>    Affects Versions: JBDEPLOY-2.2.1.GA
>            Reporter: Pontus Ullgren
>            Assignee: Ales Justin
>            Priority: Minor
>             Fix For: JBDEPLOY-2.2.2.GA
>
>         Attachments: JBDEPLOY-276.diff.gz
>
>
> A empty line in aliases.txt will result in a alias without name being created.
> This becomes obvious when two modules happens to have a empty new line in the end of the aliases.txt file the result is then 
> Caused by: java.lang.IllegalStateException: 
> _Alias_AbstractKernelController[29048474] is already installed.
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:716)
> My suggestion is to simply filter out any empty line in org.jboss.deployers.vfs.plugins.dependency.AliasesParserDeployer#parse(...).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 24 08:24:23 2011
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Sun, 24 Jul 2011 08:24:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-277) Fix declarative
 structure to handle .war files explicitly
In-Reply-To: <1832906309.78292.1311509543630.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1561780700.78306.1311510263816.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBDEPLOY-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin resolved JBDEPLOY-277.
----------------------------------

    Resolution: Done


> Fix declarative structure to handle .war files explicitly
> ---------------------------------------------------------
>
>                 Key: JBDEPLOY-277
>                 URL: https://issues.jboss.org/browse/JBDEPLOY-277
>             Project: JBoss Deployers
>          Issue Type: Task
>          Components: structure
>    Affects Versions: JBDEPLOY-2.2.1.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBDEPLOY-2.2.2.GA
>
>
> See JBAS-8786 for more details.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 24 15:38:23 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Sun, 24 Jul 2011 15:38:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1299) Interface
 resource's criteria attribute should be read-write
In-Reply-To: <1146112164.57020.1310743291902.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <543869457.78326.1311536303727.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616071#comment-12616071 ] 

Heiko Rupp commented on AS7-1299:
---------------------------------

The question is how deep the nesting really has to be. Flattened out would be best, but already restricting the level of nesting could help.

Do people really use those complex criteria? I would expect that just giving a specific IP address would be the case used most often.

> Interface resource's criteria attribute should be read-write 
> -------------------------------------------------------------
>
>                 Key: AS7-1299
>                 URL: https://issues.jboss.org/browse/AS7-1299
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.0.0.Final
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 7.0.1.Final
>
>
> http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/003123.html

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 24 23:00:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Sun, 24 Jul 2011 23:00:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1393) Make Infinispan
 default 2nd level cache provider for hibernate
In-Reply-To: <700789921.78223.1311466643701.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <774436592.78471.1311562823843.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616093#comment-12616093 ] 

Paul Ferraro commented on AS7-1393:
-----------------------------------

It's not causing any problem (I would have categorized this as a bug otherwise), but the current setup is not as simple as it could/should be.  I thought we already agreed that we would make Infinispan the default 2nd level cache provider, instead of the Hashtable impl.  We already include the requisite cache config in the default profile.

Even your suggestion doesn't go far enough, I think.  Here's what I'm proposing:
1. If hibernate.cache.use_second_level_cache is true, then default hibernate.cache.region.factory_class to "org.hibernate.cache.infinispan.JndiInfinispanRegionFactory".
2. If hibernate.cache.region.factory_class is "org.hibernate.cache.infinispan.JndiInfinispanRegionFactory" (whether explicit or implicit), then default hibernate.cache.infinispan.cachemanager to "java:jboss/infinispan/hibernate".

So, in the end, the user should only have to set 1 property in persistence.xml (i.e. <property name="hibernate.cache.use_second_level_cache" value="true"/>) in order to use the 2nd level cache with Infinispan.  That's what I mean by simple.

> Make Infinispan default 2nd level cache provider for hibernate
> --------------------------------------------------------------
>
>                 Key: AS7-1393
>                 URL: https://issues.jboss.org/browse/AS7-1393
>             Project: Application Server 7
>          Issue Type: Enhancement
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Scott Marlow
>             Fix For: 7.0.1.Final, 7.1.0.Alpha1
>
>
> I thought this was the already the case, but apparently it isn't yet.
> Users should not need to specify a value for hibernate.cache.region.factory_class in their persistence.xml.
> If undefined, the jpa subsystem should default the hibernate.cache.region.factory_class to "org.hibernate.cache.infinispan.JndiInfinispanRegionFactory".  Likewise, the requisite hibernate.cache.infinispan.cachemanager property should default to "java:jboss/infinispan/hibernate".

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 24 23:18:23 2011
From: jira-events at lists.jboss.org (George Gastaldi (JIRA))
Date: Sun, 24 Jul 2011 23:18:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1177) JavaMail not
	available
In-Reply-To: <371450412.33446.1309771103714.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <224239766.78509.1311563903687.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616096#comment-12616096 ] 

George Gastaldi commented on AS7-1177:
--------------------------------------

Should a new subsystem be created ?

> JavaMail not available
> ----------------------
>
>                 Key: AS7-1177
>                 URL: https://issues.jboss.org/browse/AS7-1177
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Modules
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>
> JavaMail cannot be used as it was in JBossAS 6 and earlier.
> 1) I tried as in JBoss 6:
> @Resource(mappedName = "java:Mail")
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:12:08,454 INFO  [org.jboss.as.server.controller] (pool-1-thread-48) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.naming.context.java.comp.\"test.ear\".test.KundenverwaltungListener.\"env/de.swe2.kundenverwaltung.service.KundenverwaltungListener/mailer\".jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.8","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Dao.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.ValidationService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Kundenverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Artikelverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.FileStore.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.RolesService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.BestellverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.PasswordService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".jndiDependencyService","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Bestellverwaltung.START"]}
> 11:12:08,468 INFO  [org.jboss.jpa] (MSC service thread 1-1) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:12:08,470 INFO  [org.jboss.weld] (MSC service thread 1-1) Stopping weld service
> 2) I tried
> @Resource
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:09:20,085 INFO  [org.jboss.as.server.controller] (pool-1-thread-46) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START"]}
> 11:09:20,094 INFO  [org.jboss.jpa] (MSC service thread 1-2) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:09:20,098 INFO  [org.jboss.weld] (MSC service thread 1-2) Stopping weld service

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul 25 00:43:23 2011
From: jira-events at lists.jboss.org (George Gastaldi (JIRA))
Date: Mon, 25 Jul 2011 00:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1177) JavaMail not
	available
In-Reply-To: <371450412.33446.1309771103714.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <957214329.78574.1311569003924.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616098#comment-12616098 ] 

George Gastaldi commented on AS7-1177:
--------------------------------------

I am starting an initial work on this subsystem in https://github.com/gastaldi/jboss-as/tree/mail/

> JavaMail not available
> ----------------------
>
>                 Key: AS7-1177
>                 URL: https://issues.jboss.org/browse/AS7-1177
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Modules
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>
> JavaMail cannot be used as it was in JBossAS 6 and earlier.
> 1) I tried as in JBoss 6:
> @Resource(mappedName = "java:Mail")
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:12:08,454 INFO  [org.jboss.as.server.controller] (pool-1-thread-48) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.naming.context.java.comp.\"test.ear\".test.KundenverwaltungListener.\"env/de.swe2.kundenverwaltung.service.KundenverwaltungListener/mailer\".jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.8","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Dao.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.ValidationService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Kundenverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Artikelverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.FileStore.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.RolesService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.BestellverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.PasswordService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".jndiDependencyService","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Bestellverwaltung.START"]}
> 11:12:08,468 INFO  [org.jboss.jpa] (MSC service thread 1-1) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:12:08,470 INFO  [org.jboss.weld] (MSC service thread 1-1) Stopping weld service
> 2) I tried
> @Resource
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:09:20,085 INFO  [org.jboss.as.server.controller] (pool-1-thread-46) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START"]}
> 11:09:20,094 INFO  [org.jboss.jpa] (MSC service thread 1-2) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:09:20,098 INFO  [org.jboss.weld] (MSC service thread 1-2) Stopping weld service

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul 25 00:51:23 2011
From: jira-events at lists.jboss.org (George Gastaldi (JIRA))
Date: Mon, 25 Jul 2011 00:51:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1177) JavaMail not
	available
In-Reply-To: <371450412.33446.1309771103714.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <394165958.78580.1311569483633.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616099#comment-12616099 ] 

George Gastaldi commented on AS7-1177:
--------------------------------------

What about the following XML subsystem config ?
 
{code:xml}
<mail-sessions>
   <mail-session name="Default">
     <property name="mail.smtp.host">localhost</property>
     <property name="mail.smtp.port">9999</property>
   </mail-session>
</mail-sessions>
{code}

> JavaMail not available
> ----------------------
>
>                 Key: AS7-1177
>                 URL: https://issues.jboss.org/browse/AS7-1177
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Modules
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>
> JavaMail cannot be used as it was in JBossAS 6 and earlier.
> 1) I tried as in JBoss 6:
> @Resource(mappedName = "java:Mail")
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:12:08,454 INFO  [org.jboss.as.server.controller] (pool-1-thread-48) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.naming.context.java.comp.\"test.ear\".test.KundenverwaltungListener.\"env/de.swe2.kundenverwaltung.service.KundenverwaltungListener/mailer\".jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.8","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Dao.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.ValidationService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Kundenverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Artikelverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.FileStore.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.RolesService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.BestellverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.PasswordService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".jndiDependencyService","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Bestellverwaltung.START"]}
> 11:12:08,468 INFO  [org.jboss.jpa] (MSC service thread 1-1) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:12:08,470 INFO  [org.jboss.weld] (MSC service thread 1-1) Stopping weld service
> 2) I tried
> @Resource
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:09:20,085 INFO  [org.jboss.as.server.controller] (pool-1-thread-46) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START"]}
> 11:09:20,094 INFO  [org.jboss.jpa] (MSC service thread 1-2) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:09:20,098 INFO  [org.jboss.weld] (MSC service thread 1-2) Stopping weld service

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul 25 01:36:23 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Mon, 25 Jul 2011 01:36:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1889) Duplicate
 messages are produced during cluster failover when a cluster node is
 shutdown
In-Reply-To: <1376159458.63243.1311086964843.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1774448488.78630.1311572183820.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1889:
--------------------------------------

    Attachment: DistributedQueueExample.java


the test that reproduces this issue

> Duplicate messages are produced during cluster failover when a cluster node is shutdown
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1889
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1889
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.8.SP1
>         Environment: JBoss EAP 5.1.1
>            Reporter: Tom Ross
>            Assignee: Yong Hao Gao
>         Attachments: DistributedQueueExample.java
>
>
> The scenarion describes a set-up consisting of JBoss cluster and a stand alone JBoss instance hosting a MDB. 
> During the test the master node of the JBoss cluster is shutdown using CTRL/C or shutdown.sh script.
> The following is a description of the events that hava happened that lead to duplicate messages.
> - Message is delivered to a MDB from node-1 of the cluster to a MDB in a transaction. The transaction prepare has failed because the server peer of node-1 is shutting down.
> - Message is rolled back and received again in another transaction. This happens at the client side only. Then the transaction is committed on node-2 as the client has failed over to node-2 of the cluster.
> - Meanwhile the fact that node-1 is shutting down causes server side failover to happen and the message is failed over to node-2.
> - node-2 redelivers the message to the MDB in a separate transaction and committs.
> So the message is received twice.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 01:45:24 2011
From: jira-events at lists.jboss.org (Jim Ma (JIRA))
Date: Mon, 25 Jul 2011 01:45:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1360) Incorrect
 soap:address connector port generated in WSDL for JAX-WS service
In-Reply-To: <1522203522.72363.1311252083923.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <892140439.78634.1311572724100.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616102#comment-12616102 ] 

Jim Ma commented on AS7-1360:
-----------------------------

Just a quick update. I've fixed this parsing error in my fork and it should be merged in AS7 upstream today or tomorrow. I continue to look at this issue to make it same behavior as in AS6/AS5.

> Incorrect soap:address connector port generated in WSDL for JAX-WS service
> --------------------------------------------------------------------------
>
>                 Key: AS7-1360
>                 URL: https://issues.jboss.org/browse/AS7-1360
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>         Environment: Ubuntu 11.04, JBoss AS 7.0.0.Final
>            Reporter: Abhijit Sarkar
>            Assignee: Jim Ma
>             Fix For: 7.0.1.Final
>
>
> Default soap:address connector port generated in WSDL even though server is running on a different HTTP port. Please see forum reference for detail.
> ??
> jaikiran pai wrote:
> Please open a JIRA for this. The way the connector port is being inferred from the configured connectors, from the JBoss WS code, will not work in AS7.
> ??

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 03:27:23 2011
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 25 Jul 2011 03:27:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-1347) UNICAST/UNICAST2:
 message can get delivered multiple times
Message-ID: <961470272.78702.1311578843655.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

UNICAST/UNICAST2: message can get delivered multiple times
----------------------------------------------------------

                 Key: JGRP-1347
                 URL: https://issues.jboss.org/browse/JGRP-1347
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 2.12.2, 3.0


In handleDataReceived(), when our connection is not the same as the conn_id of the incoming message, we (1) remove the window and (2) create a new one and add it.
However, (1) and (2) are *not* synchronized: when multiple threads go through this code concurrently, we could have a sequence 1-2-1, meaning the window is removed, a new one is created, but then - because another thread got conn_id != our conn_id true, the window will be removed again !
This means that a message #1 might get added to the new window and delivered to the app, and then the same thing could happen again, because we re-create the window again !
SOLUTION: synchronization around: check for conn_id match, removal and creation of the new window

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 04:30:23 2011
From: jira-events at lists.jboss.org (Gary Quinn (JIRA))
Date: Mon, 25 Jul 2011 04:30:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (AS7-1296) JBREM00200: Remote
 connection failed
In-Reply-To: <1442430573.56217.1310730983622.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <875246324.78800.1311582623782.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gary Quinn reopened AS7-1296:
-----------------------------



OK, it is giving the "JBREM00200: Remote connection failed" error again, even with maven installed.

> JBREM00200: Remote connection failed
> ------------------------------------
>
>                 Key: AS7-1296
>                 URL: https://issues.jboss.org/browse/AS7-1296
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Final
>            Reporter: Gary Quinn
>
> Downloaded JBoss and followed the "Installing and starting JBoss AS on Linux, Unix or Mac OS X". started the standalone server (jboss-as-7.0.0.Final/bin/standalone.sh)
> Server starts but keep logging the following error: 13:57:52,026 ERROR [org.jboss.remoting.remote] (XNIO NIO Read 1) JBREM00200: Remote connection failed: java.io.IOException: Received an invalid message length of 1195725856

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 04:30:23 2011
From: jira-events at lists.jboss.org (Gary Quinn (JIRA))
Date: Mon, 25 Jul 2011 04:30:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1296) JBREM00200: Remote
 connection failed
In-Reply-To: <1442430573.56217.1310730983622.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <392504773.78802.1311582623843.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616112#comment-12616112 ] 

Gary Quinn commented on AS7-1296:
---------------------------------

Here is the output:



gary at gary-desktop:~/data/etc/jboss/jboss-as-7.0.0.Final/bin$ java -version
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
gary at gary-desktop:~/data/etc/jboss/jboss-as-7.0.0.Final/bin$ mvn --version
Apache Maven 3.0.3 (r1075438; 2011-02-28 19:31:09+0200)
Maven home: /usr/local/apache-maven/apache-maven-3.0.3
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre
Default locale: en_ZA, platform encoding: UTF-8
OS name: "linux", version: "2.6.35-22-generic", arch: "amd64", family: "unix"
gary at gary-desktop:~/data/etc/jboss/jboss-as-7.0.0.Final/bin$ ./standalone.sh 
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /home/gary/data/etc/jboss/jboss-as-7.0.0.Final

  JAVA: java

  JAVA_OPTS: -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

=========================================================================

10:31:00,257 INFO  [org.jboss.modules] JBoss Modules version 1.0.1.GA
10:31:00,409 INFO  [org.jboss.msc] JBoss MSC version 1.0.0.GA
10:31:00,452 INFO  [org.jboss.as] JBoss AS 7.0.0.Final "Lightning" starting
10:31:00,966 INFO  [org.jboss.as] creating http management service using network interface (management) port (9990) securePort (-1)
10:31:00,975 INFO  [org.jboss.as.logging] Removing bootstrap log handlers
10:31:00,985 INFO  [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying JDBC-compliant driver class org.h2.Driver (version 1.2)
10:31:00,992 INFO  [org.jboss.as.clustering.infinispan.subsystem] (Controller Boot Thread) Activating Infinispan subsystem.
10:31:01,065 INFO  [org.jboss.as.naming] (Controller Boot Thread) Activating Naming Subsystem
10:31:01,073 INFO  [org.jboss.as.naming] (MSC service thread 1-2) Starting Naming Service 
10:31:01,075 INFO  [org.jboss.as.osgi] (Controller Boot Thread) Activating OSGi Subsystem
10:31:01,088 INFO  [org.jboss.as.security] (Controller Boot Thread) Activating Security Subsystem
10:31:01,092 INFO  [org.jboss.remoting] (MSC service thread 1-6) JBoss Remoting version 3.2.0.Beta2
10:31:01,100 INFO  [org.xnio] (MSC service thread 1-6) XNIO Version 3.0.0.Beta3
10:31:01,109 INFO  [org.xnio.nio] (MSC service thread 1-6) XNIO NIO Implementation Version 3.0.0.Beta3
10:31:01,230 INFO  [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-4) The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/lib/jvm/java-6-sun-1.6.0.24/jre/lib/amd64/server:/usr/lib/jvm/java-6-sun-1.6.0.24/jre/lib/amd64:/usr/lib/jvm/java-6-sun-1.6.0.24/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
10:31:01,240 INFO  [org.jboss.as.jmx.JMXConnectorService] (MSC service thread 1-6) Starting remote JMX connector
10:31:01,243 INFO  [org.jboss.as.ee] (Controller Boot Thread) Activating EE subsystem
10:31:01,257 INFO  [org.jboss.as.remoting] (MSC service thread 1-12) Listening on /127.0.0.1:9999
10:31:01,342 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-8) Starting Coyote HTTP/1.1 on http--127.0.0.1-8080
10:31:01,385 INFO  [org.jboss.as.connector] (MSC service thread 1-8) Starting JCA Subsystem (JBoss IronJacamar 1.0.0.CR2)
10:31:01,410 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-11) Bound data source [java:jboss/datasources/ExampleDS]
10:31:01,625 INFO  [org.jboss.as.deployment] (MSC service thread 1-5) Started FileSystemDeploymentService for directory /home/gary/data/etc/jboss/jboss-as-7.0.0.Final/standalone/deployments
10:31:01,634 INFO  [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.0.Final "Lightning" started in 1522ms - Started 92 of 147 services (55 services are passive or on-demand)
10:31:18,554 ERROR [org.jboss.remoting.remote] (XNIO NIO Read 1) JBREM00200: Remote connection failed: java.io.IOException: Received an invalid message length of 1347375956


> JBREM00200: Remote connection failed
> ------------------------------------
>
>                 Key: AS7-1296
>                 URL: https://issues.jboss.org/browse/AS7-1296
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Final
>            Reporter: Gary Quinn
>
> Downloaded JBoss and followed the "Installing and starting JBoss AS on Linux, Unix or Mac OS X". started the standalone server (jboss-as-7.0.0.Final/bin/standalone.sh)
> Server starts but keep logging the following error: 13:57:52,026 ERROR [org.jboss.remoting.remote] (XNIO NIO Read 1) JBREM00200: Remote connection failed: java.io.IOException: Received an invalid message length of 1195725856

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 04:37:25 2011
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 25 Jul 2011 04:37:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1177) JavaMail not
	available
In-Reply-To: <371450412.33446.1309771103714.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2002993952.78888.1311583045784.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616114#comment-12616114 ] 

Tomaz Cerar commented on AS7-1177:
----------------------------------

Hi,
i am already working on mail subsystem https://github.com/ctomc/jboss-as/tree/mail but I am not done yet...

As for your configuration goes, what would be the purpose of multiple mail-sessions?

my idea for config was something similar to what was in as4/5/6
like this:

{code:xml}
<subsystem xmlns="urn:jboss:domain:mail:1.0">
	<jndi-name>java:/Mail</jndi-name>
	<properties>
	  <property name="mail.store.protocol" value="pop3"/>
          <property name="mail.transport.protocol" value="smtp"/>
	</properties>
</subsystem>
{code}

wdyt?

> JavaMail not available
> ----------------------
>
>                 Key: AS7-1177
>                 URL: https://issues.jboss.org/browse/AS7-1177
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Modules
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>
> JavaMail cannot be used as it was in JBossAS 6 and earlier.
> 1) I tried as in JBoss 6:
> @Resource(mappedName = "java:Mail")
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:12:08,454 INFO  [org.jboss.as.server.controller] (pool-1-thread-48) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.naming.context.java.comp.\"test.ear\".test.KundenverwaltungListener.\"env/de.swe2.kundenverwaltung.service.KundenverwaltungListener/mailer\".jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.8","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Dao.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.ValidationService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Kundenverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Artikelverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.FileStore.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.RolesService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.BestellverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.PasswordService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".jndiDependencyService","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Bestellverwaltung.START"]}
> 11:12:08,468 INFO  [org.jboss.jpa] (MSC service thread 1-1) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:12:08,470 INFO  [org.jboss.weld] (MSC service thread 1-1) Stopping weld service
> 2) I tried
> @Resource
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:09:20,085 INFO  [org.jboss.as.server.controller] (pool-1-thread-46) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START"]}
> 11:09:20,094 INFO  [org.jboss.jpa] (MSC service thread 1-2) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:09:20,098 INFO  [org.jboss.weld] (MSC service thread 1-2) Stopping weld service

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul 25 06:02:23 2011
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 25 Jul 2011 06:02:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-1347) UNICAST/UNICAST2:
 message can get delivered multiple times
In-Reply-To: <961470272.78702.1311578843655.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1868542190.79147.1311588143770.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1347.
----------------------------

    Resolution: Done


Added synchronization around fetching the initial window. After that, messages can be added concurrently

> UNICAST/UNICAST2: message can get delivered multiple times
> ----------------------------------------------------------
>
>                 Key: JGRP-1347
>                 URL: https://issues.jboss.org/browse/JGRP-1347
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 2.12.2, 3.0
>
>
> In handleDataReceived(), when our connection is not the same as the conn_id of the incoming message, we (1) remove the window and (2) create a new one and add it.
> However, (1) and (2) are *not* synchronized: when multiple threads go through this code concurrently, we could have a sequence 1-2-1, meaning the window is removed, a new one is created, but then - because another thread got conn_id != our conn_id true, the window will be removed again !
> This means that a message #1 might get added to the new window and delivered to the app, and then the same thing could happen again, because we re-create the window again !
> SOLUTION: synchronization around: check for conn_id match, removal and creation of the new window

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 06:04:23 2011
From: jira-events at lists.jboss.org (Phil Haigh (JIRA))
Date: Mon, 25 Jul 2011 06:04:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-201) JBoss Web Native
 causes JVM crash
In-Reply-To: <1610434667.259.1307874923304.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <634954233.79153.1311588263740.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616168#comment-12616168 ] 

Phil Haigh commented on JBWEB-201:
----------------------------------

Hi Remy,

I do not know. This issue was 100% reproducible though, on different platforms. Every time the server was started, it would crash out after a few mins at most.





> JBoss Web Native causes JVM crash
> ---------------------------------
>
>                 Key: JBWEB-201
>                 URL: https://issues.jboss.org/browse/JBWEB-201
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat
>    Affects Versions: JBossWeb-3.0.0.CR1
>         Environment: RHEL x64. JBoss AS 6.0.0.Final
>            Reporter: Phil Haigh
>            Assignee: Remy Maucherat
>              Labels: jboss, native
>         Attachments: hs_err_pid14823.log
>
>
> Install latest JBoss native (2.0.9) libraries on JBossAS 6.0.0.Final (which uses JBoss Web 3.0.0.CR1), JDK 1.6.0_26  and JVM crashes out soon after application start.
> Snippet from crash report (full file attached):
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x00002aaab5b0f468, pid=14823, tid=1191192896
> #
> # JRE version: 6.0_26-b03
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.1-b02 mixed mode linux-amd64 compressed oops)
> # Problematic frame:
> # C  [libapr-1.so.0+0x1d468]  signed char+0x68
> #
> # If you would like to submit a bug report, please visit:
> #   http://java.sun.com/webapps/bugreport/crash.jsp
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #
> ---------------  T H R E A D  ---------------
> Current thread (0x00002aaac2d09000):  JavaThread "ajp-127.0.0.1-8009-Poller" daemon [_thread_in_native, id=15006, stack(0x0000000046
> f02000,0x0000000047003000)]
> siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000000000008
> Registers:
> RAX=0x0000000000000000, RBX=0x0000000047001ad0, RCX=0x0000000047001a90, RDX=0x00002aaac453f688
> RSP=0x0000000047001a90, RBP=0x00002aaac2d06b38, RSI=0x0000000000000001, RDI=0x0000000000000259
> R8 =0x0000000000000001, R9 =0x00002aaac453f688, R10=0x00002aaaab02eadf, R11=0x00002ba6c4d23170
> R12=0x00002aaac453f688, R13=0x0000000047001a90, R14=0x0000000000000000, R15=0x00002aaac2d09000
> RIP=0x00002aaab5b0f468, EFLAGS=0x0000000000010206, CSGSFS=0x0000000000000033, ERR=0x0000000000000004
>   TRAPNO=0x000000000000000e
> Top of Stack: (sp=0x0000000047001a90)
> 0x0000000047001a90:   c453f68800000001 00002ba600002aaa
> 0x0000000047001aa0:   00002aaac4f365f8 0000000047001ad0
> 0x0000000047001ab0:   0000000000000000 00000007ea4d0e58
> 0x0000000047001ac0:   0000000047001bb8 00002aaab564c147
> 0x0000000047001ad0:   0000000000000000 0000000100000001
> 0x0000000047001ae0:   0000000000000000 00000000514505e8
> 0x0000000047001af0:   00002aaac2d09000 00000007ea4d0e58
> 0x0000000047001b00:   0000000047001b78 00002aaaab02eb0c
> 0x0000000047001b10:   0000000000000001 00000007e002ee78
> 0x0000000047001b20:   0000000000000000 0000000047001bb8
> 0x0000000047001b30:   0000000047001b88 0000000047001b38
> 0x0000000047001b40:   0000000000000000 0000000047001bb8
> 0x0000000047001b50:   00000007ea4d1788 0000000000000000
> 0x0000000047001b60:   00000007ea4d0e58 0000000000000000
> 0x0000000047001b70:   0000000047001b98 0000000047001c00
> 0x0000000047001b80:   00002aaaab02296e 00000007ea4d16b8
> 0x0000000047001b90:   00002aaaab02b8d6 0000000000000001
> 0x0000000047001ba0:   00000000514505e8 00002aaaab022a82
> 0x0000000047001bb0:   00002aaac4f365f8 000000077bfff118
> 0x0000000047001bc0:   0000000047001bc0 00000007ea4beb73
> 0x0000000047001bd0:   0000000047001c38 00000007ea4c2f18
> 0x0000000047001be0:   0000000000000000 00000007ea4bebf0
> 0x0000000047001bf0:   0000000047001b98 0000000047001c20
> 0x0000000047001c00:   0000000047001c90 00002aaaab02285a
> 0x0000000047001c10:   0000000000000000 00000000ffffffff
> 0x0000000047001c20:   0000000000000001 00000000514505e8
> 0x0000000047001c30:   000000077c01bc68 000000077b6059e8
> 0x0000000047001c40:   0000000000000009 0000000000000000
> 0x0000000047001c50:   0000000047001c40 00000007ea4bf518
> 0x0000000047001c60:   0000000047001ce0 00000007ea4c2f18
> 0x0000000047001c70:   00000007ea74b790 00000007ea4bfac0
> 0x0000000047001c80:   0000000047001c20 0000000047001ce0 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 06:06:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 25 Jul 2011 06:06:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1393) Make Infinispan
 default 2nd level cache provider for hibernate
In-Reply-To: <700789921.78223.1311466643701.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <215578857.79158.1311588383704.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616170#comment-12616170 ] 

Scott Marlow commented on AS7-1393:
-----------------------------------

Great suggestion, thanks for creating the jira!  :)



> Make Infinispan default 2nd level cache provider for hibernate
> --------------------------------------------------------------
>
>                 Key: AS7-1393
>                 URL: https://issues.jboss.org/browse/AS7-1393
>             Project: Application Server 7
>          Issue Type: Enhancement
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Scott Marlow
>             Fix For: 7.0.1.Final, 7.1.0.Alpha1
>
>
> I thought this was the already the case, but apparently it isn't yet.
> Users should not need to specify a value for hibernate.cache.region.factory_class in their persistence.xml.
> If undefined, the jpa subsystem should default the hibernate.cache.region.factory_class to "org.hibernate.cache.infinispan.JndiInfinispanRegionFactory".  Likewise, the requisite hibernate.cache.infinispan.cachemanager property should default to "java:jboss/infinispan/hibernate".

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 06:09:23 2011
From: jira-events at lists.jboss.org (Karel Piwko (JIRA))
Date: Mon, 25 Jul 2011 06:09:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-689) Add JGit
 repository to Maven repository
Message-ID: <1031274966.79166.1311588563657.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Add JGit repository to Maven repository
---------------------------------------

                 Key: JBBUILD-689
                 URL: https://issues.jboss.org/browse/JBBUILD-689
             Project: JBoss Build System
          Issue Type: Feature Request
          Components: Artifact Repositories
            Reporter: Karel Piwko



Please add repository [1] to our Nexus instance. I'm using
this dependency in Arquillian OpenShift Express container and
having a extra repository defined in pom is not a way how we should do
it.

{code}
<repositories>
    <repository>
        <id>jgit-repository</id>
        <url>http://download.eclipse.org/jgit/maven</url>
    </repository>
</repositories>
{code}


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 07:24:23 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Mon, 25 Jul 2011 07:24:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1889) Duplicate
 messages are produced during cluster failover when a cluster node is
 shutdown
In-Reply-To: <1376159458.63243.1311086964843.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <10201557.79286.1311593063689.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBMESSAGING-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616198#comment-12616198 ] 

Yong Hao Gao commented on JBMESSAGING-1889:
-------------------------------------------

To reproduce:

Set up a 2 node cluster (server peer id 1 and 2). 
Start up the cluster and run the attached test (it comes from jbm example distributed-queue. put it in the example and run 'ant' is a simple way to run it).
The tests creates a connection consumer and then send a message. The connection consumer receives the message in a fake XA transaction branch. Before it commits it will prompt you to kill node 1 and it waits for the failover and does the commit on the failed over connection.

You can see the message have received twice.



> Duplicate messages are produced during cluster failover when a cluster node is shutdown
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1889
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1889
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.8.SP1
>         Environment: JBoss EAP 5.1.1
>            Reporter: Tom Ross
>            Assignee: Yong Hao Gao
>         Attachments: DistributedQueueExample.java
>
>
> The scenarion describes a set-up consisting of JBoss cluster and a stand alone JBoss instance hosting a MDB. 
> During the test the master node of the JBoss cluster is shutdown using CTRL/C or shutdown.sh script.
> The following is a description of the events that hava happened that lead to duplicate messages.
> - Message is delivered to a MDB from node-1 of the cluster to a MDB in a transaction. The transaction prepare has failed because the server peer of node-1 is shutting down.
> - Message is rolled back and received again in another transaction. This happens at the client side only. Then the transaction is committed on node-2 as the client has failed over to node-2 of the cluster.
> - Meanwhile the fact that node-1 is shutting down causes server side failover to happen and the message is failed over to node-2.
> - node-2 redelivers the message to the MDB in a separate transaction and committs.
> So the message is received twice.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 07:29:23 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Mon, 25 Jul 2011 07:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1889) Duplicate
 messages are produced during cluster failover when a cluster node is
 shutdown
In-Reply-To: <1376159458.63243.1311086964843.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1035560198.79291.1311593363736.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBMESSAGING-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616199#comment-12616199 ] 

Yong Hao Gao commented on JBMESSAGING-1889:
-------------------------------------------

The problem is that the ConnectionConsumer uses an internal non-transactional session to receive messages and then the messages were dispatched to server sessions, which can be a transactional session. However the commit of transaction is done through the internal session. During failover, JBM will recover messages that not acked/committed, but as the acks list goes with the internal session, which is non tx one, so JBM won't get the correct ACK list. The result is that the message that has been delivered won't get correctly processed at the server side, therefore the message will be delivered again.


> Duplicate messages are produced during cluster failover when a cluster node is shutdown
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1889
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1889
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.8.SP1
>         Environment: JBoss EAP 5.1.1
>            Reporter: Tom Ross
>            Assignee: Yong Hao Gao
>         Attachments: DistributedQueueExample.java
>
>
> The scenarion describes a set-up consisting of JBoss cluster and a stand alone JBoss instance hosting a MDB. 
> During the test the master node of the JBoss cluster is shutdown using CTRL/C or shutdown.sh script.
> The following is a description of the events that hava happened that lead to duplicate messages.
> - Message is delivered to a MDB from node-1 of the cluster to a MDB in a transaction. The transaction prepare has failed because the server peer of node-1 is shutting down.
> - Message is rolled back and received again in another transaction. This happens at the client side only. Then the transaction is committed on node-2 as the client has failed over to node-2 of the cluster.
> - Meanwhile the fact that node-1 is shutting down causes server side failover to happen and the message is failed over to node-2.
> - node-2 redelivers the message to the MDB in a separate transaction and committs.
> So the message is received twice.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 07:39:23 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Mon, 25 Jul 2011 07:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1889) Duplicate
 messages are produced during cluster failover when a cluster node is
 shutdown
In-Reply-To: <1376159458.63243.1311086964843.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1474488740.79302.1311593963724.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao updated JBMESSAGING-1889:
--------------------------------------

        Fix Version/s: 1.4.0.SP3.CP15
                       1.4.8.SP3
    Affects Version/s: 1.4.8.SP2
                       1.4.0.SP3.CP14


> Duplicate messages are produced during cluster failover when a cluster node is shutdown
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1889
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1889
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP14, 1.4.8.SP1, 1.4.8.SP2
>         Environment: JBoss EAP 5.1.1
>            Reporter: Tom Ross
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>         Attachments: DistributedQueueExample.java
>
>
> The scenarion describes a set-up consisting of JBoss cluster and a stand alone JBoss instance hosting a MDB. 
> During the test the master node of the JBoss cluster is shutdown using CTRL/C or shutdown.sh script.
> The following is a description of the events that hava happened that lead to duplicate messages.
> - Message is delivered to a MDB from node-1 of the cluster to a MDB in a transaction. The transaction prepare has failed because the server peer of node-1 is shutting down.
> - Message is rolled back and received again in another transaction. This happens at the client side only. Then the transaction is committed on node-2 as the client has failed over to node-2 of the cluster.
> - Meanwhile the fact that node-1 is shutting down causes server side failover to happen and the message is failed over to node-2.
> - node-2 redelivers the message to the MDB in a separate transaction and committs.
> So the message is received twice.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 08:35:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 25 Jul 2011 08:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1394) Add a WARN message if
 AS7 is running unsecured or if AS7 is running with the sample realm with
 the default of admin=admin
Message-ID: <1924274729.79428.1311597323784.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Add a WARN message if AS7 is running unsecured or if AS7 is running with the sample realm with the default of admin=admin
-------------------------------------------------------------------------------------------------------------------------

                 Key: AS7-1394
                 URL: https://issues.jboss.org/browse/AS7-1394
             Project: Application Server 7
          Issue Type: Task
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 7.1.0.Beta1


Whilst end users are free to configure the server as they choose we should at least log a warning to alert them to the fact their server has not been secured, if they want out of the box easy starts without security then they can ignore the warnings.

At least one other user has reported enabling security but the security not being applied, actually one of the steps to secure the server has been missed so the presence of a WARN message that disappears after correct configuration will also enable users to better see it is enabled.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 08:35:23 2011
From: jira-events at lists.jboss.org (George Gastaldi (JIRA))
Date: Mon, 25 Jul 2011 08:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1177) JavaMail not
	available
In-Reply-To: <371450412.33446.1309771103714.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <388290726.79426.1311597323728.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616213#comment-12616213 ] 

George Gastaldi commented on AS7-1177:
--------------------------------------

Yes, support for multiple sessions is necessary as my environment has multiple mail servers


> JavaMail not available
> ----------------------
>
>                 Key: AS7-1177
>                 URL: https://issues.jboss.org/browse/AS7-1177
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Modules
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>
> JavaMail cannot be used as it was in JBossAS 6 and earlier.
> 1) I tried as in JBoss 6:
> @Resource(mappedName = "java:Mail")
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:12:08,454 INFO  [org.jboss.as.server.controller] (pool-1-thread-48) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.naming.context.java.comp.\"test.ear\".test.KundenverwaltungListener.\"env/de.swe2.kundenverwaltung.service.KundenverwaltungListener/mailer\".jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.8","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Dao.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.ValidationService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Kundenverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Artikelverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.FileStore.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.RolesService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.BestellverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.PasswordService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".jndiDependencyService","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Bestellverwaltung.START"]}
> 11:12:08,468 INFO  [org.jboss.jpa] (MSC service thread 1-1) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:12:08,470 INFO  [org.jboss.weld] (MSC service thread 1-1) Stopping weld service
> 2) I tried
> @Resource
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:09:20,085 INFO  [org.jboss.as.server.controller] (pool-1-thread-46) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START"]}
> 11:09:20,094 INFO  [org.jboss.jpa] (MSC service thread 1-2) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:09:20,098 INFO  [org.jboss.weld] (MSC service thread 1-2) Stopping weld service

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul 25 08:37:24 2011
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 25 Jul 2011 08:37:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-3143) Knowledge Agent
 does not handle multiple packages in Builder output from single resource
In-Reply-To: <1469969996.55952.1310723183785.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <393677868.79459.1311597444404.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBRULES-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli resolved JBRULES-3143.
------------------------------------

    Resolution: Done


Closing the ticket as it seems it is working. Wolfgang's latest e-mail:

==========
My last pull from upstream and recompile was done
   2011-07-22 17:56 drools-compiler-5.3.0-SNAPSHOT.jar
and I did see some changes in KBuilder and KAgent - I vividly recall being curious about the fix and going through the latter (git show) and seeing that multiple packages were passed from KB into KA's code. It seems that I did this immediately after seeing Edson's mail announcing the resolution and close of 3143. (I suppose the JIRA update was done *after* updating the central repository.)

Now I pull again and, once more, I see changes in PackageBuilder and KAImp. After compiling and rerunning the tests I can confirm that this test is OK now.


> Knowledge Agent does not handle multiple packages in Builder output from single resource
> ----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3143
>                 URL: https://issues.jboss.org/browse/JBRULES-3143
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions: 5.2.0.Final
>            Reporter: Wolfgang Laun
>            Assignee: Edson Tirelli
>            Priority: Blocker
>             Fix For: 5.2.1.Final, 5.3.0.Beta1
>
>
> Note: see also https://issues.jboss.org/browse/JBRULES-2940
> KnowledgeAgent with a ChecngeSet containing a single DRL:
>    package x
>    import y.Type
>    declare Type
>       @role(event)
>    end
>    //...rules etc.
> If this is passed to the builder, it'll return two KnowledgePackageImpl objects, one with name 'x' and another one with name 'y'. But the KA only takes the first package from the Collection of packages returned by the builder.
> =!=> KA must process all packages from the builder.
> =!=> Incremental kBase building requires diff-ing between old/new packages. This, then, must take into account that contribution to one package can come from several resource builds.
> =!=> The idea that the kBuilder should return packages with different names from a single DRL build is probably wrong. If a Drools package foo contains an import bar.Type, then this is still an asset in package foo and needs to be handled as a type reference in foo. Any annotation additions must be carried by that asset foo. (The *Java* package of the imported bar.Type remains of course bar.)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 08:37:24 2011
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Mon, 25 Jul 2011 08:37:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-3143) Knowledge Agent
 does not handle multiple packages in Builder output from single resource
In-Reply-To: <1469969996.55952.1310723183785.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1012274359.79464.1311597444568.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBRULES-3143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli closed JBRULES-3143.
----------------------------------



> Knowledge Agent does not handle multiple packages in Builder output from single resource
> ----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3143
>                 URL: https://issues.jboss.org/browse/JBRULES-3143
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions: 5.2.0.Final
>            Reporter: Wolfgang Laun
>            Assignee: Edson Tirelli
>            Priority: Blocker
>             Fix For: 5.2.1.Final, 5.3.0.Beta1
>
>
> Note: see also https://issues.jboss.org/browse/JBRULES-2940
> KnowledgeAgent with a ChecngeSet containing a single DRL:
>    package x
>    import y.Type
>    declare Type
>       @role(event)
>    end
>    //...rules etc.
> If this is passed to the builder, it'll return two KnowledgePackageImpl objects, one with name 'x' and another one with name 'y'. But the KA only takes the first package from the Collection of packages returned by the builder.
> =!=> KA must process all packages from the builder.
> =!=> Incremental kBase building requires diff-ing between old/new packages. This, then, must take into account that contribution to one package can come from several resource builds.
> =!=> The idea that the kBuilder should return packages with different names from a single DRL build is probably wrong. If a Drools package foo contains an import bar.Type, then this is still an asset in package foo and needs to be handled as a type reference in foo. Any annotation additions must be carried by that asset foo. (The *Java* package of the imported bar.Type remains of course bar.)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 08:41:23 2011
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 25 Jul 2011 08:41:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1177) JavaMail not
	available
In-Reply-To: <371450412.33446.1309771103714.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <859789939.79488.1311597683793.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616217#comment-12616217 ] 

Tomaz Cerar commented on AS7-1177:
----------------------------------

Agree with you, I have found some old issues from previous versions of jboss where some good examples ware posted, see JBAS-7883
currently my version "config" is something like that:

{code:xml}
 <subsystem xmlns="urn:jboss:domain:mail:1.0">
            <mail-session jndi-name="java:/Mail">
                <username>nobody</username>
                <password>password</password>
                <properties>
                    <property name="mail.smtp.host">localhost</property>
                    <property name="mail.smtp.port">9999</property>
                </properties>
           </mail-session>
            <mail-session jndi-name="foo/MyMailServer1">
                <username>myuser</username>
                <password>mypassword</password>
                <properties>
                    <property name="mail.smtp.host">localhost</property>
                    <property name="mail.smtp.port">9999</property>
                </properties>
           </mail-session>
        </subsystem>
{code}

parsing already works, now I am working on implementation

> JavaMail not available
> ----------------------
>
>                 Key: AS7-1177
>                 URL: https://issues.jboss.org/browse/AS7-1177
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Modules
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>
> JavaMail cannot be used as it was in JBossAS 6 and earlier.
> 1) I tried as in JBoss 6:
> @Resource(mappedName = "java:Mail")
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:12:08,454 INFO  [org.jboss.as.server.controller] (pool-1-thread-48) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.naming.context.java.comp.\"test.ear\".test.KundenverwaltungListener.\"env/de.swe2.kundenverwaltung.service.KundenverwaltungListener/mailer\".jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.8","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Dao.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.ValidationService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Kundenverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Artikelverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.FileStore.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.RolesService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.BestellverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.PasswordService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".jndiDependencyService","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Bestellverwaltung.START"]}
> 11:12:08,468 INFO  [org.jboss.jpa] (MSC service thread 1-1) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:12:08,470 INFO  [org.jboss.weld] (MSC service thread 1-1) Stopping weld service
> 2) I tried
> @Resource
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:09:20,085 INFO  [org.jboss.as.server.controller] (pool-1-thread-46) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START"]}
> 11:09:20,094 INFO  [org.jboss.jpa] (MSC service thread 1-2) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:09:20,098 INFO  [org.jboss.weld] (MSC service thread 1-2) Stopping weld service

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul 25 08:45:23 2011
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 25 Jul 2011 08:45:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1177) JavaMail not
	available
In-Reply-To: <371450412.33446.1309771103714.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1231706763.79501.1311597923751.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned AS7-1177:
--------------------------------

    Assignee: Tomaz Cerar


> JavaMail not available
> ----------------------
>
>                 Key: AS7-1177
>                 URL: https://issues.jboss.org/browse/AS7-1177
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Modules
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: Tomaz Cerar
>
> JavaMail cannot be used as it was in JBossAS 6 and earlier.
> 1) I tried as in JBoss 6:
> @Resource(mappedName = "java:Mail")
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:12:08,454 INFO  [org.jboss.as.server.controller] (pool-1-thread-48) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.naming.context.java.comp.\"test.ear\".test.KundenverwaltungListener.\"env/de.swe2.kundenverwaltung.service.KundenverwaltungListener/mailer\".jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.8","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Dao.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.ValidationService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Kundenverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Artikelverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.FileStore.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.RolesService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.BestellverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.PasswordService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".jndiDependencyService","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Bestellverwaltung.START"]}
> 11:12:08,468 INFO  [org.jboss.jpa] (MSC service thread 1-1) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:12:08,470 INFO  [org.jboss.weld] (MSC service thread 1-1) Stopping weld service
> 2) I tried
> @Resource
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:09:20,085 INFO  [org.jboss.as.server.controller] (pool-1-thread-46) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START"]}
> 11:09:20,094 INFO  [org.jboss.jpa] (MSC service thread 1-2) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:09:20,098 INFO  [org.jboss.weld] (MSC service thread 1-2) Stopping weld service

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul 25 09:51:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 25 Jul 2011 09:51:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1177) JavaMail not
	available
In-Reply-To: <371450412.33446.1309771103714.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1165755987.79754.1311601883787.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616248#comment-12616248 ] 

David Lloyd commented on AS7-1177:
----------------------------------

Looks good *except* that the mail host/port should not be properties like this.  It should use the existing socket binding registry infrastructure instead.

> JavaMail not available
> ----------------------
>
>                 Key: AS7-1177
>                 URL: https://issues.jboss.org/browse/AS7-1177
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Modules
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: Tomaz Cerar
>
> JavaMail cannot be used as it was in JBossAS 6 and earlier.
> 1) I tried as in JBoss 6:
> @Resource(mappedName = "java:Mail")
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:12:08,454 INFO  [org.jboss.as.server.controller] (pool-1-thread-48) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.naming.context.java.comp.\"test.ear\".test.KundenverwaltungListener.\"env/de.swe2.kundenverwaltung.service.KundenverwaltungListener/mailer\".jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.8","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Dao.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.ValidationService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Kundenverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Artikelverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.FileStore.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.RolesService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.BestellverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.PasswordService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".jndiDependencyService","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Bestellverwaltung.START"]}
> 11:12:08,468 INFO  [org.jboss.jpa] (MSC service thread 1-1) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:12:08,470 INFO  [org.jboss.weld] (MSC service thread 1-1) Stopping weld service
> 2) I tried
> @Resource
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:09:20,085 INFO  [org.jboss.as.server.controller] (pool-1-thread-46) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START"]}
> 11:09:20,094 INFO  [org.jboss.jpa] (MSC service thread 1-2) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:09:20,098 INFO  [org.jboss.weld] (MSC service thread 1-2) Stopping weld service

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul 25 09:57:23 2011
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 25 Jul 2011 09:57:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1177) JavaMail not
	available
In-Reply-To: <371450412.33446.1309771103714.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <419912863.79808.1311602243793.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616252#comment-12616252 ] 

Tomaz Cerar commented on AS7-1177:
----------------------------------

That might good for host name and port what about other properties:
for example: (all props from example mail-service.xml)
{code:xml}
<mail-session jndi-name="java:/Mail">
                <username>nobody</username>
                <password>password</password>
                <properties>                
                    <property name="mail.store.protocol">pop3</property>
                    <property name="mail.transport.protocol">smtp</property>
                    <property name="mail.user">nobody</property>
                    <property name="mail.pop3.host">pop3.nosuchhost.nosuchdomain.com</property>
                    <property name="mail.smtp.host">smtp.nosuchhost.nosuchdomain.com</property>
                    <property name="mail.smtp.port">25</property>
                    <property name="mail.from">nobody at nosuchhost.nosuchdomain.com</property>
                    <property name="mail.debug">false</property>
                </properties>
           </mail-session>
{code}

> JavaMail not available
> ----------------------
>
>                 Key: AS7-1177
>                 URL: https://issues.jboss.org/browse/AS7-1177
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Modules
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: Tomaz Cerar
>
> JavaMail cannot be used as it was in JBossAS 6 and earlier.
> 1) I tried as in JBoss 6:
> @Resource(mappedName = "java:Mail")
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:12:08,454 INFO  [org.jboss.as.server.controller] (pool-1-thread-48) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.naming.context.java.comp.\"test.ear\".test.KundenverwaltungListener.\"env/de.swe2.kundenverwaltung.service.KundenverwaltungListener/mailer\".jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.8","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Dao.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.ValidationService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Kundenverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Artikelverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.FileStore.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.RolesService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.BestellverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.PasswordService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".jndiDependencyService","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Bestellverwaltung.START"]}
> 11:12:08,468 INFO  [org.jboss.jpa] (MSC service thread 1-1) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:12:08,470 INFO  [org.jboss.weld] (MSC service thread 1-1) Stopping weld service
> 2) I tried
> @Resource
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:09:20,085 INFO  [org.jboss.as.server.controller] (pool-1-thread-46) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START"]}
> 11:09:20,094 INFO  [org.jboss.jpa] (MSC service thread 1-2) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:09:20,098 INFO  [org.jboss.weld] (MSC service thread 1-2) Stopping weld service

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul 25 10:03:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 25 Jul 2011 10:03:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1177) JavaMail not
	available
In-Reply-To: <371450412.33446.1309771103714.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <142554685.79828.1311602603704.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616253#comment-12616253 ] 

David Lloyd commented on AS7-1177:
----------------------------------

Correction.  The binding registry should be used to specify a source address.  The session destination should probably be configured per-session.  And, user name information should *definitely* be attributes, and password information should only be indirectly accessed:

{code:xml}
  <mail-session jndi-name="mail-server-1">
      <login name="nobody" password="xxxx"/>
      <smtp-server bind="socket-binding-name" address="localhost" port="9999"/>
  </mail-session>
{code}

Asking the security guys about passwords and obfuscation/indirection.

Relative JNDI names should maybe default to "java:jboss/mail/" + the relative name.

> JavaMail not available
> ----------------------
>
>                 Key: AS7-1177
>                 URL: https://issues.jboss.org/browse/AS7-1177
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Modules
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: Tomaz Cerar
>
> JavaMail cannot be used as it was in JBossAS 6 and earlier.
> 1) I tried as in JBoss 6:
> @Resource(mappedName = "java:Mail")
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:12:08,454 INFO  [org.jboss.as.server.controller] (pool-1-thread-48) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.naming.context.java.comp.\"test.ear\".test.KundenverwaltungListener.\"env/de.swe2.kundenverwaltung.service.KundenverwaltungListener/mailer\".jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.8","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Dao.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.ValidationService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Kundenverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Artikelverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.FileStore.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.RolesService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.BestellverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.PasswordService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".jndiDependencyService","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Bestellverwaltung.START"]}
> 11:12:08,468 INFO  [org.jboss.jpa] (MSC service thread 1-1) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:12:08,470 INFO  [org.jboss.weld] (MSC service thread 1-1) Stopping weld service
> 2) I tried
> @Resource
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:09:20,085 INFO  [org.jboss.as.server.controller] (pool-1-thread-46) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START"]}
> 11:09:20,094 INFO  [org.jboss.jpa] (MSC service thread 1-2) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:09:20,098 INFO  [org.jboss.weld] (MSC service thread 1-2) Stopping weld service

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul 25 10:05:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 25 Jul 2011 10:05:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1177) JavaMail not
	available
In-Reply-To: <371450412.33446.1309771103714.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <896716987.79837.1311602723932.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616254#comment-12616254 ] 

David Lloyd commented on AS7-1177:
----------------------------------

Using generic properties like this to configure subsystems is generally not allowed, as tooling has a hard time dealing with it.

> JavaMail not available
> ----------------------
>
>                 Key: AS7-1177
>                 URL: https://issues.jboss.org/browse/AS7-1177
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Modules
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: Tomaz Cerar
>
> JavaMail cannot be used as it was in JBossAS 6 and earlier.
> 1) I tried as in JBoss 6:
> @Resource(mappedName = "java:Mail")
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:12:08,454 INFO  [org.jboss.as.server.controller] (pool-1-thread-48) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.naming.context.java.comp.\"test.ear\".test.KundenverwaltungListener.\"env/de.swe2.kundenverwaltung.service.KundenverwaltungListener/mailer\".jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.8","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Dao.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.ValidationService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Kundenverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Artikelverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.FileStore.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.RolesService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.BestellverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.PasswordService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".jndiDependencyService","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Bestellverwaltung.START"]}
> 11:12:08,468 INFO  [org.jboss.jpa] (MSC service thread 1-1) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:12:08,470 INFO  [org.jboss.weld] (MSC service thread 1-1) Stopping weld service
> 2) I tried
> @Resource
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:09:20,085 INFO  [org.jboss.as.server.controller] (pool-1-thread-46) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START"]}
> 11:09:20,094 INFO  [org.jboss.jpa] (MSC service thread 1-2) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:09:20,098 INFO  [org.jboss.weld] (MSC service thread 1-2) Stopping weld service

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul 25 10:09:24 2011
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 25 Jul 2011 10:09:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1177) JavaMail not
	available
In-Reply-To: <371450412.33446.1309771103714.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1709425341.79851.1311602964075.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616256#comment-12616256 ] 

Tomaz Cerar commented on AS7-1177:
----------------------------------

Ok, I will change the code/configuration according to your guidelines and get rid of "generic" properties

> JavaMail not available
> ----------------------
>
>                 Key: AS7-1177
>                 URL: https://issues.jboss.org/browse/AS7-1177
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Modules
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: Tomaz Cerar
>
> JavaMail cannot be used as it was in JBossAS 6 and earlier.
> 1) I tried as in JBoss 6:
> @Resource(mappedName = "java:Mail")
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:12:08,454 INFO  [org.jboss.as.server.controller] (pool-1-thread-48) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.naming.context.java.comp.\"test.ear\".test.KundenverwaltungListener.\"env/de.swe2.kundenverwaltung.service.KundenverwaltungListener/mailer\".jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.8","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Dao.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.ValidationService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Kundenverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Artikelverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.FileStore.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.RolesService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.BestellverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.PasswordService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".jndiDependencyService","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Bestellverwaltung.START"]}
> 11:12:08,468 INFO  [org.jboss.jpa] (MSC service thread 1-1) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:12:08,470 INFO  [org.jboss.weld] (MSC service thread 1-1) Stopping weld service
> 2) I tried
> @Resource
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:09:20,085 INFO  [org.jboss.as.server.controller] (pool-1-thread-46) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START"]}
> 11:09:20,094 INFO  [org.jboss.jpa] (MSC service thread 1-2) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:09:20,098 INFO  [org.jboss.weld] (MSC service thread 1-2) Stopping weld service

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul 25 10:09:24 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 25 Jul 2011 10:09:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1177) Implement JavaMail
In-Reply-To: <371450412.33446.1309771103714.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <153335306.79863.1311602964398.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated AS7-1177:
-----------------------------

       Summary: Implement JavaMail  (was: JavaMail not available)
    Issue Type: Feature Request  (was: Bug)


> Implement JavaMail
> ------------------
>
>                 Key: AS7-1177
>                 URL: https://issues.jboss.org/browse/AS7-1177
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Modules
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: Tomaz Cerar
>
> JavaMail cannot be used as it was in JBossAS 6 and earlier.
> 1) I tried as in JBoss 6:
> @Resource(mappedName = "java:Mail")
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:12:08,454 INFO  [org.jboss.as.server.controller] (pool-1-thread-48) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.naming.context.java.comp.\"test.ear\".test.KundenverwaltungListener.\"env/de.swe2.kundenverwaltung.service.KundenverwaltungListener/mailer\".jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.8","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Dao.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.ValidationService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Kundenverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Artikelverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.FileStore.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.RolesService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.BestellverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.PasswordService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".jndiDependencyService","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Bestellverwaltung.START"]}
> 11:12:08,468 INFO  [org.jboss.jpa] (MSC service thread 1-1) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:12:08,470 INFO  [org.jboss.weld] (MSC service thread 1-1) Stopping weld service
> 2) I tried
> @Resource
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:09:20,085 INFO  [org.jboss.as.server.controller] (pool-1-thread-46) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START"]}
> 11:09:20,094 INFO  [org.jboss.jpa] (MSC service thread 1-2) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:09:20,098 INFO  [org.jboss.weld] (MSC service thread 1-2) Stopping weld service

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul 25 10:39:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 25 Jul 2011 10:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-2245) BMT interceptor
 doesn't take into account application exceptions
In-Reply-To: <126239372.22184.1302610713212.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <336285567.79904.1311604763682.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/EJBTHREE-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated EJBTHREE-2245:
-----------------------------------

    Fix Version/s:     (was: depchain-1.0.2)


> BMT interceptor doesn't take into account application exceptions
> ----------------------------------------------------------------
>
>                 Key: EJBTHREE-2245
>                 URL: https://issues.jboss.org/browse/EJBTHREE-2245
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: transactions
>    Affects Versions: depchain-1.0.0-alpha-47
>         Environment: JBoss AS 6.0.0.Final
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> BMT interceptors currently don't check for application exception semantics as mandated by EJB3 spec. See EJB3.1 spec section 14.3.1, Table 16 for details.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 10:41:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 25 Jul 2011 10:41:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (EJBTHREE-2263) @SecurityDomain
 doesn't work with @Singleton
In-Reply-To: <219269068.7313.1302073474413.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <60585290.79908.1311604883917.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/EJBTHREE-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai moved JBAS-9244 to EJBTHREE-2263:
----------------------------------------------

                     Project: EJB 3.0  (was: Legacy JBoss Application Server 6 )
                         Key: EJBTHREE-2263  (was: JBAS-9244)
           Affects Version/s: depchain-1.0.1
                              depchain-1.0.0
                                  (was: 6.0.0.Final)
    Component Fix Version(s): jboss-ejb3-singleton:1.0.1
                 Component/s: Security
                              singleton
                                  (was: Security)
                                  (was: EJB)
                    Security:     (was: Public)
               Fix Version/s: depchain-1.0.2
                                  (was: 6.1.0)


> @SecurityDomain doesn't work with @Singleton
> --------------------------------------------
>
>                 Key: EJBTHREE-2263
>                 URL: https://issues.jboss.org/browse/EJBTHREE-2263
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: Security, singleton
>    Affects Versions: depchain-1.0.1, depchain-1.0.0
>         Environment: Windows Vista, java version "1.6.0_23"
>            Reporter: Christian Reiter
>            Assignee: jaikiran pai
>              Labels: security_domain, singleton
>             Fix For: depchain-1.0.2
>
>         Attachments: login-config.zip, SingletonAuthTest_Client.zip, SingletonAuthTest_EE_App.zip, SingletonAuthTest_Interfaces.zip
>
>
> In Jboss AS 6 (6.0.0.Final) the Annotation @SecurityDomain from the package org.jboss.ejb3.annotation.SecurityDomain doesn't seem to work with @Singleton - SessionBeans.
> If I try to call a method from a @Singleton which is marked with @RolesAllowed i get a "java.lang.IllegalStateException: Security Context has not been set" Exception. If I do completely the same with a @Stateless SessionBean everything works fine.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 10:41:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 25 Jul 2011 10:41:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-2263) @SecurityDomain
 doesn't work with @Singleton
In-Reply-To: <219269068.7313.1302073474413.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <914223826.79916.1311604884157.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/EJBTHREE-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-2263.
------------------------------------

    Resolution: Done


Fixed in jboss-ejb3-singleton 1.0.1 release

> @SecurityDomain doesn't work with @Singleton
> --------------------------------------------
>
>                 Key: EJBTHREE-2263
>                 URL: https://issues.jboss.org/browse/EJBTHREE-2263
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: Security, singleton
>    Affects Versions: depchain-1.0.0, depchain-1.0.1
>         Environment: Windows Vista, java version "1.6.0_23"
>            Reporter: Christian Reiter
>            Assignee: jaikiran pai
>              Labels: security_domain, singleton
>             Fix For: depchain-1.0.2
>
>         Attachments: login-config.zip, SingletonAuthTest_Client.zip, SingletonAuthTest_EE_App.zip, SingletonAuthTest_Interfaces.zip
>
>
> In Jboss AS 6 (6.0.0.Final) the Annotation @SecurityDomain from the package org.jboss.ejb3.annotation.SecurityDomain doesn't seem to work with @Singleton - SessionBeans.
> If I try to call a method from a @Singleton which is marked with @RolesAllowed i get a "java.lang.IllegalStateException: Security Context has not been set" Exception. If I do completely the same with a @Stateless SessionBean everything works fine.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 11:17:23 2011
From: jira-events at lists.jboss.org (Burkhard Vogel (JIRA))
Date: Mon, 25 Jul 2011 11:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3152) Control of
 KnowledgeAgent instances
Message-ID: <413611220.80127.1311607043970.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Control of KnowledgeAgent instances
-----------------------------------

                 Key: JBRULES-3152
                 URL: https://issues.jboss.org/browse/JBRULES-3152
             Project: Drools
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
    Affects Versions: 5.2.0.Final
            Reporter: Burkhard Vogel
            Assignee: Mark Proctor


There should be a way limit the number of KA on a server - as I restart test-clients and redeploy my client apps they tend to accumulate. Shouldn't the KA name be unique and any reference to a KA with the same name recover the already created KA? Or shouldn't all KA created by a client app (web or standalone) die when the creating app terminates?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 11:19:24 2011
From: jira-events at lists.jboss.org (Burkhard Vogel (JIRA))
Date: Mon, 25 Jul 2011 11:19:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3153) ChangeSet loading
 will take 5 minutes without an internet conection
Message-ID: <1637447010.80150.1311607164149.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

ChangeSet loading will take 5 minutes without an internet conection
-------------------------------------------------------------------

                 Key: JBRULES-3153
                 URL: https://issues.jboss.org/browse/JBRULES-3153
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.2.0.Final
            Reporter: Burkhard Vogel
            Assignee: Mark Proctor


My knowledge agent takes about 5 min to read the changeset.xml, it happens an my servers that DON'T have internet access when reading (or better trying to read) http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-api/src/main/resources/change-set-1.0.0.xsd - however its included in the knowledge-api jar.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 11:29:23 2011
From: jira-events at lists.jboss.org (George Gastaldi (JIRA))
Date: Mon, 25 Jul 2011 11:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1177) Implement JavaMail
In-Reply-To: <371450412.33446.1309771103714.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1893208666.80238.1311607763863.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616272#comment-12616272 ] 

George Gastaldi commented on AS7-1177:
--------------------------------------

One option is to place all the "mail." properties as attributes in <mail-session> element and create an element for SMTP as attributes as well as other protocols:

For Example: 

{code:xml}
<mail-session jndi-name="xyz" debug="true" from="abc at xyz.com" user="nobody">
   <smtp bind="socket-binding-name"/>
</mail-session>
{code}

> Implement JavaMail
> ------------------
>
>                 Key: AS7-1177
>                 URL: https://issues.jboss.org/browse/AS7-1177
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Modules
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: Tomaz Cerar
>
> JavaMail cannot be used as it was in JBossAS 6 and earlier.
> 1) I tried as in JBoss 6:
> @Resource(mappedName = "java:Mail")
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:12:08,454 INFO  [org.jboss.as.server.controller] (pool-1-thread-48) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.naming.context.java.comp.\"test.ear\".test.KundenverwaltungListener.\"env/de.swe2.kundenverwaltung.service.KundenverwaltungListener/mailer\".jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.8","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Dao.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.ValidationService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Kundenverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Artikelverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.FileStore.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.RolesService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.BestellverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.PasswordService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".jndiDependencyService","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Bestellverwaltung.START"]}
> 11:12:08,468 INFO  [org.jboss.jpa] (MSC service thread 1-1) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:12:08,470 INFO  [org.jboss.weld] (MSC service thread 1-1) Stopping weld service
> 2) I tried
> @Resource
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:09:20,085 INFO  [org.jboss.as.server.controller] (pool-1-thread-46) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START"]}
> 11:09:20,094 INFO  [org.jboss.jpa] (MSC service thread 1-2) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:09:20,098 INFO  [org.jboss.weld] (MSC service thread 1-2) Stopping weld service

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Mon Jul 25 11:34:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 25 Jul 2011 11:34:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-2263)
 @SecurityDomain doesn't work with @Singleton
In-Reply-To: <219269068.7313.1302073474413.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <40418265.80255.1311608063677.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/EJBTHREE-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616275#comment-12616275 ] 

jaikiran pai commented on EJBTHREE-2263:
----------------------------------------

Try out the latest AS6 nightly build (containing r111829). That should have this fix.


> @SecurityDomain doesn't work with @Singleton
> --------------------------------------------
>
>                 Key: EJBTHREE-2263
>                 URL: https://issues.jboss.org/browse/EJBTHREE-2263
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: Security, singleton
>    Affects Versions: depchain-1.0.0, depchain-1.0.1
>         Environment: Windows Vista, java version "1.6.0_23"
>            Reporter: Christian Reiter
>            Assignee: jaikiran pai
>              Labels: security_domain, singleton
>             Fix For: depchain-1.0.2
>
>         Attachments: login-config.zip, SingletonAuthTest_Client.zip, SingletonAuthTest_EE_App.zip, SingletonAuthTest_Interfaces.zip
>
>
> In Jboss AS 6 (6.0.0.Final) the Annotation @SecurityDomain from the package org.jboss.ejb3.annotation.SecurityDomain doesn't seem to work with @Singleton - SessionBeans.
> If I try to call a method from a @Singleton which is marked with @RolesAllowed i get a "java.lang.IllegalStateException: Security Context has not been set" Exception. If I do completely the same with a @Stateless SessionBean everything works fine.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 11:46:24 2011
From: jira-events at lists.jboss.org (Aron Ujvari (JIRA))
Date: Mon, 25 Jul 2011 11:46:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1300) Management console
 doesn't work after changing management interface port
In-Reply-To: <1695801765.57097.1310744483645.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <90856037.80289.1311608784272.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616278#comment-12616278 ] 

Aron Ujvari commented on AS7-1300:
----------------------------------

I can confirm that this problem exists in standalone mode also.

> Management console doesn't work after changing management interface port
> ------------------------------------------------------------------------
>
>                 Key: AS7-1300
>                 URL: https://issues.jboss.org/browse/AS7-1300
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Console
>    Affects Versions: 7.0.0.Final
>            Reporter: Sebastian Wanio
>            Assignee: Heiko Braun
>              Labels: console, http, jboss, port
>
> After changing http management port in _host.xml_ console stops working. 
> Changing it back to default 9990 fixes the issue. 
> It seems it s GWT related and 9990 port is "hardcoded" in java script files. 
> Every script named _32.cache.js_ in _modules\org\jboss\com\sun\httpserver\main\jboss-as-console-1.0.0.Beta13-resources.jar_ has some variable set to ':9990/'. (only one occurrence in a file)
> After changing its value to match a new http management port in _host.xml_ (other than 9990) and repackaging of _jboss-as-console-1.0.0.Beta13-resources.jar_ console starts working again. 
> _Note! Checked only on domain mode. Not testes in standalone._

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 11:50:24 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 25 Jul 2011 11:50:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1300) Management console
 doesn't work after changing management interface port
In-Reply-To: <1695801765.57097.1310744483645.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <954466678.80301.1311609024086.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated AS7-1300:
-----------------------------

    Fix Version/s: 7.0.1.Final


> Management console doesn't work after changing management interface port
> ------------------------------------------------------------------------
>
>                 Key: AS7-1300
>                 URL: https://issues.jboss.org/browse/AS7-1300
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Console
>    Affects Versions: 7.0.0.Final
>            Reporter: Sebastian Wanio
>            Assignee: Heiko Braun
>              Labels: console, http, jboss, port
>             Fix For: 7.0.1.Final
>
>
> After changing http management port in _host.xml_ console stops working. 
> Changing it back to default 9990 fixes the issue. 
> It seems it s GWT related and 9990 port is "hardcoded" in java script files. 
> Every script named _32.cache.js_ in _modules\org\jboss\com\sun\httpserver\main\jboss-as-console-1.0.0.Beta13-resources.jar_ has some variable set to ':9990/'. (only one occurrence in a file)
> After changing its value to match a new http management port in _host.xml_ (other than 9990) and repackaging of _jboss-as-console-1.0.0.Beta13-resources.jar_ console starts working again. 
> _Note! Checked only on domain mode. Not testes in standalone._

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 12:29:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 25 Jul 2011 12:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1300) Management console
 doesn't work after changing management interface port
In-Reply-To: <1695801765.57097.1310744483645.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2046745887.80412.1311611363658.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616292#comment-12616292 ] 

Heiko Braun commented on AS7-1300:
----------------------------------

yeah, right. thanks for the notice. I think this is actually one of the first TODO comments I put in the code six month ago. It simply got forgotten ;)

> Management console doesn't work after changing management interface port
> ------------------------------------------------------------------------
>
>                 Key: AS7-1300
>                 URL: https://issues.jboss.org/browse/AS7-1300
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Console
>    Affects Versions: 7.0.0.Final
>            Reporter: Sebastian Wanio
>            Assignee: Heiko Braun
>              Labels: console, http, jboss, port
>             Fix For: 7.0.1.Final
>
>
> After changing http management port in _host.xml_ console stops working. 
> Changing it back to default 9990 fixes the issue. 
> It seems it s GWT related and 9990 port is "hardcoded" in java script files. 
> Every script named _32.cache.js_ in _modules\org\jboss\com\sun\httpserver\main\jboss-as-console-1.0.0.Beta13-resources.jar_ has some variable set to ':9990/'. (only one occurrence in a file)
> After changing its value to match a new http management port in _host.xml_ (other than 9990) and repackaging of _jboss-as-console-1.0.0.Beta13-resources.jar_ console starts working again. 
> _Note! Checked only on domain mode. Not testes in standalone._

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 12:42:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 25 Jul 2011 12:42:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1300) Management console
 doesn't work after changing management interface port
In-Reply-To: <1695801765.57097.1310744483645.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <527968839.80419.1311612143685.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun resolved AS7-1300.
------------------------------

    Resolution: Done


will ship with 7.0.1

> Management console doesn't work after changing management interface port
> ------------------------------------------------------------------------
>
>                 Key: AS7-1300
>                 URL: https://issues.jboss.org/browse/AS7-1300
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Console
>    Affects Versions: 7.0.0.Final
>            Reporter: Sebastian Wanio
>            Assignee: Heiko Braun
>              Labels: console, http, jboss, port
>             Fix For: 7.0.1.Final
>
>
> After changing http management port in _host.xml_ console stops working. 
> Changing it back to default 9990 fixes the issue. 
> It seems it s GWT related and 9990 port is "hardcoded" in java script files. 
> Every script named _32.cache.js_ in _modules\org\jboss\com\sun\httpserver\main\jboss-as-console-1.0.0.Beta13-resources.jar_ has some variable set to ':9990/'. (only one occurrence in a file)
> After changing its value to match a new http management port in _host.xml_ (other than 9990) and repackaging of _jboss-as-console-1.0.0.Beta13-resources.jar_ console starts working again. 
> _Note! Checked only on domain mode. Not testes in standalone._

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 13:56:23 2011
From: jira-events at lists.jboss.org (Michael Anstis (JIRA))
Date: Mon, 25 Jul 2011 13:56:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3154) Date handling in
	XLS tables
Message-ID: <2002636360.80552.1311616583693.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Date handling in XLS tables
---------------------------

                 Key: JBRULES-3154
                 URL: https://issues.jboss.org/browse/JBRULES-3154
             Project: Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Michael Anstis
            Assignee: Michael Anstis


Dates set in a XLS sheet are not read correctly under Guvnor. It seems that XLS reading transforms the date into a format that can't be properly handled by compiler.

Example (in the repository_export.xml attached file) :

    * My XLS has a column that tests a java.util.Date against a value : "myDate >= $param"
    * My XLS cell contains a date, formatted by Excel (may be that's the reason) using a English format like the Guvnor default one, ie : dd-MMM-yyyy. The example date value is "01-Jan-2009" (the display, the internal value in XLS is a number...)

Problems (at compilation and DRl generation) :

    * Unable to create a Field value of type 'ValueType = 'Date'' and value '"1-janv.-2009"' : notice that the date value has been transformed !
    * This value ("janv." instead of "jan") is certainly due to the fact that I am french ("janvier" is the french for "january")

    * If I reset the french default format, ie dd/MM/yyyy, the value 01/01/2009 is tranformed to 01/01/09, and the compilation complains about unknown format (same error).

    * If I turn the excel cell in text format, and enter "01-jan-2009", there no value transformation anymore, and the rule compiles OK.

So I guess that reading dates in the XLS is the source of the problem.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 13:58:23 2011
From: jira-events at lists.jboss.org (Michael Anstis (JIRA))
Date: Mon, 25 Jul 2011 13:58:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-3154) Date handling in
	XLS tables
In-Reply-To: <2002636360.80552.1311616583693.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <691298492.80564.1311616703729.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBRULES-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis updated JBRULES-3154:
------------------------------------

    Affects Version/s: 5.2.0.Final
          Component/s: drools-decisiontables


> Date handling in XLS tables
> ---------------------------
>
>                 Key: JBRULES-3154
>                 URL: https://issues.jboss.org/browse/JBRULES-3154
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-decisiontables
>    Affects Versions: 5.2.0.Final
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> Dates set in a XLS sheet are not read correctly under Guvnor. It seems that XLS reading transforms the date into a format that can't be properly handled by compiler.
> Example (in the repository_export.xml attached file) :
>     * My XLS has a column that tests a java.util.Date against a value : "myDate >= $param"
>     * My XLS cell contains a date, formatted by Excel (may be that's the reason) using a English format like the Guvnor default one, ie : dd-MMM-yyyy. The example date value is "01-Jan-2009" (the display, the internal value in XLS is a number...)
> Problems (at compilation and DRl generation) :
>     * Unable to create a Field value of type 'ValueType = 'Date'' and value '"1-janv.-2009"' : notice that the date value has been transformed !
>     * This value ("janv." instead of "jan") is certainly due to the fact that I am french ("janvier" is the french for "january")
>     * If I reset the french default format, ie dd/MM/yyyy, the value 01/01/2009 is tranformed to 01/01/09, and the compilation complains about unknown format (same error).
>     * If I turn the excel cell in text format, and enter "01-jan-2009", there no value transformation anymore, and the rule compiles OK.
> So I guess that reading dates in the XLS is the source of the problem.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 14:00:23 2011
From: jira-events at lists.jboss.org (Michael Anstis (JIRA))
Date: Mon, 25 Jul 2011 14:00:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3154) Date handling
	in XLS tables
In-Reply-To: <2002636360.80552.1311616583693.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <828588662.80568.1311616823752.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616308#comment-12616308 ] 

Michael Anstis commented on JBRULES-3154:
-----------------------------------------

Workaround: Don't use excel cell's formatting to date, use text format ... and use either the default format "dd-MMM-yyyy" or the one you set in "drools.dateformat" system property.

> Date handling in XLS tables
> ---------------------------
>
>                 Key: JBRULES-3154
>                 URL: https://issues.jboss.org/browse/JBRULES-3154
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-decisiontables
>    Affects Versions: 5.2.0.Final
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> Dates set in a XLS sheet are not read correctly under Guvnor. It seems that XLS reading transforms the date into a format that can't be properly handled by compiler.
> Example (in the repository_export.xml attached file) :
>     * My XLS has a column that tests a java.util.Date against a value : "myDate >= $param"
>     * My XLS cell contains a date, formatted by Excel (may be that's the reason) using a English format like the Guvnor default one, ie : dd-MMM-yyyy. The example date value is "01-Jan-2009" (the display, the internal value in XLS is a number...)
> Problems (at compilation and DRl generation) :
>     * Unable to create a Field value of type 'ValueType = 'Date'' and value '"1-janv.-2009"' : notice that the date value has been transformed !
>     * This value ("janv." instead of "jan") is certainly due to the fact that I am french ("janvier" is the french for "january")
>     * If I reset the french default format, ie dd/MM/yyyy, the value 01/01/2009 is tranformed to 01/01/09, and the compilation complains about unknown format (same error).
>     * If I turn the excel cell in text format, and enter "01-jan-2009", there no value transformation anymore, and the rule compiles OK.
> So I guess that reading dates in the XLS is the source of the problem.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 14:00:23 2011
From: jira-events at lists.jboss.org (Michael Anstis (JIRA))
Date: Mon, 25 Jul 2011 14:00:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3154) Date handling
	in XLS tables
In-Reply-To: <2002636360.80552.1311616583693.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <299330082.80571.1311616823865.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616309#comment-12616309 ] 

Michael Anstis commented on JBRULES-3154:
-----------------------------------------

All values in a XLS based Decision Table are currently considered "text". This JIRA should be considered as a request to make the data-type handling better when parsing XLS Decision Tables. The underlying jxl.Cell class does support different types.

> Date handling in XLS tables
> ---------------------------
>
>                 Key: JBRULES-3154
>                 URL: https://issues.jboss.org/browse/JBRULES-3154
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-decisiontables
>    Affects Versions: 5.2.0.Final
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> Dates set in a XLS sheet are not read correctly under Guvnor. It seems that XLS reading transforms the date into a format that can't be properly handled by compiler.
> Example (in the repository_export.xml attached file) :
>     * My XLS has a column that tests a java.util.Date against a value : "myDate >= $param"
>     * My XLS cell contains a date, formatted by Excel (may be that's the reason) using a English format like the Guvnor default one, ie : dd-MMM-yyyy. The example date value is "01-Jan-2009" (the display, the internal value in XLS is a number...)
> Problems (at compilation and DRl generation) :
>     * Unable to create a Field value of type 'ValueType = 'Date'' and value '"1-janv.-2009"' : notice that the date value has been transformed !
>     * This value ("janv." instead of "jan") is certainly due to the fact that I am french ("janvier" is the french for "january")
>     * If I reset the french default format, ie dd/MM/yyyy, the value 01/01/2009 is tranformed to 01/01/09, and the compilation complains about unknown format (same error).
>     * If I turn the excel cell in text format, and enter "01-jan-2009", there no value transformation anymore, and the rule compiles OK.
> So I guess that reading dates in the XLS is the source of the problem.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 14:02:23 2011
From: jira-events at lists.jboss.org (Michael Anstis (JIRA))
Date: Mon, 25 Jul 2011 14:02:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3154) Date handling
	in XLS tables
In-Reply-To: <2002636360.80552.1311616583693.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1790451935.80577.1311616943747.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-3154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616311#comment-12616311 ] 

Michael Anstis commented on JBRULES-3154:
-----------------------------------------

Comment from OP (Vincent Legendre): Should add a warning in the doc then. May be that the fix is shorter to do...
The Date problem is common with XLS (POI has exactly the same problem), but there, the displayed value is not the one rendered in the DRL, which is a problem (in my opinion).

> Date handling in XLS tables
> ---------------------------
>
>                 Key: JBRULES-3154
>                 URL: https://issues.jboss.org/browse/JBRULES-3154
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-decisiontables
>    Affects Versions: 5.2.0.Final
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> Dates set in a XLS sheet are not read correctly under Guvnor. It seems that XLS reading transforms the date into a format that can't be properly handled by compiler.
> Example (in the repository_export.xml attached file) :
>     * My XLS has a column that tests a java.util.Date against a value : "myDate >= $param"
>     * My XLS cell contains a date, formatted by Excel (may be that's the reason) using a English format like the Guvnor default one, ie : dd-MMM-yyyy. The example date value is "01-Jan-2009" (the display, the internal value in XLS is a number...)
> Problems (at compilation and DRl generation) :
>     * Unable to create a Field value of type 'ValueType = 'Date'' and value '"1-janv.-2009"' : notice that the date value has been transformed !
>     * This value ("janv." instead of "jan") is certainly due to the fact that I am french ("janvier" is the french for "january")
>     * If I reset the french default format, ie dd/MM/yyyy, the value 01/01/2009 is tranformed to 01/01/09, and the compilation complains about unknown format (same error).
>     * If I turn the excel cell in text format, and enter "01-jan-2009", there no value transformation anymore, and the rule compiles OK.
> So I guess that reading dates in the XLS is the source of the problem.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 14:10:23 2011
From: jira-events at lists.jboss.org (Michael Anstis (JIRA))
Date: Mon, 25 Jul 2011 14:10:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-1889) figures not
 properly displayed in Drools Expert User Guide
In-Reply-To: <29072392.1228826387148.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <293064431.80583.1311617423834.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616312#comment-12616312 ] 

Michael Anstis commented on JBRULES-1889:
-----------------------------------------

Only figure 1.1 (of those listed) exist in the Drools Expert user-guide from 5.1 onwards, and it appears to be correctly displayed.

> figures not properly displayed in Drools Expert User Guide
> ----------------------------------------------------------
>
>                 Key: JBRULES-1889
>                 URL: https://issues.jboss.org/browse/JBRULES-1889
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-docs-expert
>    Affects Versions: 5.0.0.M3
>            Reporter: Jaroslaw Kijanowski
>            Assignee: Michael Anstis
>             Fix For: 5.3.0.Beta1
>
>
> Affected figures:
> 1.1.; 1.4.; 1.5

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 14:10:23 2011
From: jira-events at lists.jboss.org (Michael Anstis (JIRA))
Date: Mon, 25 Jul 2011 14:10:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1889) figures not
 properly displayed in Drools Expert User Guide
In-Reply-To: <29072392.1228826387148.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1434061043.80587.1311617423923.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBRULES-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis resolved JBRULES-1889.
-------------------------------------

    Resolution: Out of Date


> figures not properly displayed in Drools Expert User Guide
> ----------------------------------------------------------
>
>                 Key: JBRULES-1889
>                 URL: https://issues.jboss.org/browse/JBRULES-1889
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-docs-expert
>    Affects Versions: 5.0.0.M3
>            Reporter: Jaroslaw Kijanowski
>            Assignee: Michael Anstis
>             Fix For: 5.3.0.Beta1
>
>
> Affected figures:
> 1.1.; 1.4.; 1.5

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 14:16:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 25 Jul 2011 14:16:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1395) Domain Management
 Security - Remote Repository Caching
Message-ID: <1397630400.80592.1311617783845.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Domain Management Security - Remote Repository Caching
------------------------------------------------------

                 Key: AS7-1395
                 URL: https://issues.jboss.org/browse/AS7-1395
             Project: Application Server 7
          Issue Type: Task
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 7.1.0.Beta1


Where we are accessing remote stores for the users we need a cache for the information retrieved, will need features such as an expiration time and a possibility to flush the whole cache or individual entries.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 14:20:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 25 Jul 2011 14:20:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1396) Domain Management
 Security - Implement support to delegate auth request to master domain
 controller.
Message-ID: <288509096.80611.1311618023663.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Domain Management Security - Implement support to delegate auth request to master domain controller.
----------------------------------------------------------------------------------------------------

                 Key: AS7-1396
                 URL: https://issues.jboss.org/browse/AS7-1396
             Project: Application Server 7
          Issue Type: Task
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 7.1.0.Beta1


The purpose of this is so that a host controller can be configured to delegate the callback handling to the master domain controller - this effectively means that only the master domain controller is used to authenticate the user and the indovidual hosts do not need local realm configuration.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 14:22:24 2011
From: jira-events at lists.jboss.org (Michael Anstis (JIRA))
Date: Mon, 25 Jul 2011 14:22:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-1787) Undocumented
 Panels for Eclipse Guided Rule Editor
In-Reply-To: <26535521.1222404621342.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1735339487.80629.1311618144126.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBRULES-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis resolved JBRULES-1787.
-------------------------------------

    Resolution: Out of Date


We don't support the "Guided Rule Editor" (like that in Guvnor) in Eclipse as from 5.2.0.Final. User-guide update.

> Undocumented Panels for Eclipse Guided Rule Editor
> --------------------------------------------------
>
>                 Key: JBRULES-1787
>                 URL: https://issues.jboss.org/browse/JBRULES-1787
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-docs
>    Affects Versions: 4.0.7
>            Reporter: Steve Nunez (Illation)
>            Assignee: Michael Anstis
>             Fix For: 5.3.0.Beta1
>
>
> In the Guided Rule Editor section:
> http://downloads.jboss.com/drools/docs/4.0.7.19894.GA/html_single/index.html#d0e2364
> There is an explanation of the guided editor. However there is no explanation of what to expect to see in the various tabs, except the first one.
> What I expect to see in the "Generated DRL (read-only)" tab is the actual DRL that will be sent to the compiler, similar to that we see in the "DRL
> Viewer" pane of a .dslr file.
> What I actually see is the same sort of text that I see in the .dslr file, with no idea if it's actually be rendered correctly (in a subsequent step).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 15:59:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Mon, 25 Jul 2011 15:59:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1385) make storeAsBinary
	configurable
In-Reply-To: <232705938.76868.1311342323827.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <398861961.80862.1311623963663.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616332#comment-12616332 ] 

Paul Ferraro commented on AS7-1385:
-----------------------------------

You cannot disable this in AS7.  Modular classloading will cause NoClassDefFoundErrors or ClassNotFoundException if the infinispan module attempts to serialize or deserialize user objects.  The current storeAsBinary settings ensure that user objects are only serialized/deserialized when the TCCL of the application is available.  Note that the default storeAsBinary settings are cache mode dependent.  See here:
https://github.com/jbossas/jboss-as/blob/master/clustering/infinispan/src/main/resources/infinispan-defaults.xml

Unless there is sufficient objection, I'm going to reject this jira.

> make storeAsBinary configurable
> -------------------------------
>
>                 Key: AS7-1385
>                 URL: https://issues.jboss.org/browse/AS7-1385
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.Final
>            Reporter: Michal Linhard
>            Assignee: Paul Ferraro
>
> we need be able to turn on/off these infinispan config options
> infinispan.configuration.storeAsBinary.enabled
> infinispan.configuration.lazyDeserialization.enabled
> it's not yet known what causes performance degradation in JBPAPP-6865,
> but we need to be able to eliminate effect of these params

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 16:01:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Mon, 25 Jul 2011 16:01:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1385) make storeAsBinary
	configurable
In-Reply-To: <232705938.76868.1311342323827.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <9993331.80870.1311624083706.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro resolved AS7-1385.
-------------------------------

    Resolution: Rejected


> make storeAsBinary configurable
> -------------------------------
>
>                 Key: AS7-1385
>                 URL: https://issues.jboss.org/browse/AS7-1385
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.0.0.Final
>            Reporter: Michal Linhard
>            Assignee: Paul Ferraro
>
> we need be able to turn on/off these infinispan config options
> infinispan.configuration.storeAsBinary.enabled
> infinispan.configuration.lazyDeserialization.enabled
> it's not yet known what causes performance degradation in JBPAPP-6865,
> but we need to be able to eliminate effect of these params

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 17:14:23 2011
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Mon, 25 Jul 2011 17:14:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1397) JPS executable not
	found
Message-ID: <1625953177.81023.1311628463845.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

JPS executable not found
------------------------

                 Key: AS7-1397
                 URL: https://issues.jboss.org/browse/AS7-1397
             Project: Application Server 7
          Issue Type: Bug
            Reporter: James Perkins
            Assignee: James Perkins
             Fix For: 7.1.0.Alpha1


org.jboss.as.test.integration.respawn.RespawnTestCase: java.io.IOException: Cannot run program "/usr/java/jdk1.6.0_26/jre/bin/jps": java.io.IOException: error=2, No such file or directory.

The JPS executable does not appear to be located in the JRE home.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 17:21:23 2011
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Mon, 25 Jul 2011 17:21:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1397) JPS executable not
	found
In-Reply-To: <1625953177.81023.1311628463845.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <396591319.81028.1311628883696.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated AS7-1397:
-------------------------------

    Git Pull Request: https://github.com/jamezp/jboss-as/commit/d936e8b2d89d49ccc05a2f3750989fd630c8215b


> JPS executable not found
> ------------------------
>
>                 Key: AS7-1397
>                 URL: https://issues.jboss.org/browse/AS7-1397
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 7.1.0.Alpha1
>
>
> org.jboss.as.test.integration.respawn.RespawnTestCase: java.io.IOException: Cannot run program "/usr/java/jdk1.6.0_26/jre/bin/jps": java.io.IOException: error=2, No such file or directory.
> The JPS executable does not appear to be located in the JRE home.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 17:21:23 2011
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Mon, 25 Jul 2011 17:21:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1397) JPS executable not
	found
In-Reply-To: <1625953177.81023.1311628463845.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <108277980.81031.1311628883784.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated AS7-1397:
-------------------------------

    Git Pull Request:   (was: https://github.com/jamezp/jboss-as/commit/d936e8b2d89d49ccc05a2f3750989fd630c8215b)


> JPS executable not found
> ------------------------
>
>                 Key: AS7-1397
>                 URL: https://issues.jboss.org/browse/AS7-1397
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 7.1.0.Alpha1
>
>
> org.jboss.as.test.integration.respawn.RespawnTestCase: java.io.IOException: Cannot run program "/usr/java/jdk1.6.0_26/jre/bin/jps": java.io.IOException: error=2, No such file or directory.
> The JPS executable does not appear to be located in the JRE home.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 17:21:23 2011
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Mon, 25 Jul 2011 17:21:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1397) JPS executable not
	found
In-Reply-To: <1625953177.81023.1311628463845.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1708211713.81035.1311628883923.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins resolved AS7-1397.
--------------------------------

    Resolution: Done


Pull request sent, pending merge. https://github.com/jamezp/jboss-as/commit/d936e8b2d89d49ccc05a2f3750989fd630c8215b

> JPS executable not found
> ------------------------
>
>                 Key: AS7-1397
>                 URL: https://issues.jboss.org/browse/AS7-1397
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 7.1.0.Alpha1
>
>
> org.jboss.as.test.integration.respawn.RespawnTestCase: java.io.IOException: Cannot run program "/usr/java/jdk1.6.0_26/jre/bin/jps": java.io.IOException: error=2, No such file or directory.
> The JPS executable does not appear to be located in the JRE home.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 17:23:23 2011
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Mon, 25 Jul 2011 17:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (AS7-1397) JPS executable not
	found
In-Reply-To: <1625953177.81023.1311628463845.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2142253854.81038.1311629003622.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins reopened AS7-1397:
--------------------------------



Wait to resolve until merged.

> JPS executable not found
> ------------------------
>
>                 Key: AS7-1397
>                 URL: https://issues.jboss.org/browse/AS7-1397
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 7.1.0.Alpha1
>
>
> org.jboss.as.test.integration.respawn.RespawnTestCase: java.io.IOException: Cannot run program "/usr/java/jdk1.6.0_26/jre/bin/jps": java.io.IOException: error=2, No such file or directory.
> The JPS executable does not appear to be located in the JRE home.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 19:27:23 2011
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 25 Jul 2011 19:27:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-9422) Minimal server fails
 to start due to CNFE
Message-ID: <1168294145.81133.1311636443614.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Minimal server fails to start due to CNFE
-----------------------------------------

                 Key: JBAS-9422
                 URL: https://issues.jboss.org/browse/JBAS-9422
             Project: Legacy JBoss Application Server 6 
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Shelly McGowan
             Fix For: 6.1.0


Failed to boot JBoss:
java.lang.Exception: Encountered exception in server startup
	at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.bootstrapMcAndDescriptors(AbstractMCServerBase.java:350)
	at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.doStart(AbstractMCServerBase.java:282)
	at org.jboss.bootstrap.impl.as.server.AbstractJBossASServerBase.doStart(AbstractJBossASServerBase.java:381)
	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:413)
	at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.IllegalStateException: Incompletely deployed:

DEPLOYMENTS IN ERROR:
  Deployment "DeclaredStructure" is in error due to: java.lang.ClassNotFoundException: org.jboss.deployment.ExplicitDeclaredStructure

	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.internalValidate(AbstractKernelDeployer.java:278)
	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.validate(AbstractKernelDeployer.java:174)
	at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.bootstrapMcAndDescriptors(AbstractMCServerBase.java:339)


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 19:29:23 2011
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 25 Jul 2011 19:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-9422) Minimal server fails
 to start due to CNFE
In-Reply-To: <1168294145.81133.1311636443614.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <282967166.81136.1311636563631.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBAS-9422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-9422:
---------------------------------

    Attachment: boot.log


> Minimal server fails to start due to CNFE
> -----------------------------------------
>
>                 Key: JBAS-9422
>                 URL: https://issues.jboss.org/browse/JBAS-9422
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Shelly McGowan
>             Fix For: 6.1.0
>
>         Attachments: boot.log
>
>
> Failed to boot JBoss:
> java.lang.Exception: Encountered exception in server startup
> 	at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.bootstrapMcAndDescriptors(AbstractMCServerBase.java:350)
> 	at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.doStart(AbstractMCServerBase.java:282)
> 	at org.jboss.bootstrap.impl.as.server.AbstractJBossASServerBase.doStart(AbstractJBossASServerBase.java:381)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:413)
> 	at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.IllegalStateException: Incompletely deployed:
> DEPLOYMENTS IN ERROR:
>   Deployment "DeclaredStructure" is in error due to: java.lang.ClassNotFoundException: org.jboss.deployment.ExplicitDeclaredStructure
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.internalValidate(AbstractKernelDeployer.java:278)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.validate(AbstractKernelDeployer.java:174)
> 	at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.bootstrapMcAndDescriptors(AbstractMCServerBase.java:339)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 19:40:23 2011
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 25 Jul 2011 19:40:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-9422) Minimal server
 fails to start due to CNFE
In-Reply-To: <1168294145.81133.1311636443614.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <623826524.81144.1311637223666.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBAS-9422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan reassigned JBAS-9422:
------------------------------------

    Assignee: jaikiran pai


Looks related to this commit:
http://source.jboss.org/changelog/JBossAS6/?cs=111792

Failing to start minimal is inteferring with the full test suite run.

> Minimal server fails to start due to CNFE
> -----------------------------------------
>
>                 Key: JBAS-9422
>                 URL: https://issues.jboss.org/browse/JBAS-9422
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Shelly McGowan
>            Assignee: jaikiran pai
>             Fix For: 6.1.0
>
>         Attachments: boot.log
>
>
> Failed to boot JBoss:
> java.lang.Exception: Encountered exception in server startup
> 	at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.bootstrapMcAndDescriptors(AbstractMCServerBase.java:350)
> 	at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.doStart(AbstractMCServerBase.java:282)
> 	at org.jboss.bootstrap.impl.as.server.AbstractJBossASServerBase.doStart(AbstractJBossASServerBase.java:381)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:413)
> 	at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.IllegalStateException: Incompletely deployed:
> DEPLOYMENTS IN ERROR:
>   Deployment "DeclaredStructure" is in error due to: java.lang.ClassNotFoundException: org.jboss.deployment.ExplicitDeclaredStructure
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.internalValidate(AbstractKernelDeployer.java:278)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.validate(AbstractKernelDeployer.java:174)
> 	at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.bootstrapMcAndDescriptors(AbstractMCServerBase.java:339)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Mon Jul 25 21:33:23 2011
From: jira-events at lists.jboss.org (George Gastaldi (JIRA))
Date: Mon, 25 Jul 2011 21:33:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1177) Implement JavaMail
In-Reply-To: <371450412.33446.1309771103714.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1828545302.81195.1311644003677.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616379#comment-12616379 ] 

George Gastaldi commented on AS7-1177:
--------------------------------------

Tomaz, I would like to help you on implementing this. Is that possible ? 

> Implement JavaMail
> ------------------
>
>                 Key: AS7-1177
>                 URL: https://issues.jboss.org/browse/AS7-1177
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Modules
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: Tomaz Cerar
>
> JavaMail cannot be used as it was in JBossAS 6 and earlier.
> 1) I tried as in JBoss 6:
> @Resource(mappedName = "java:Mail")
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:12:08,454 INFO  [org.jboss.as.server.controller] (pool-1-thread-48) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.naming.context.java.comp.\"test.ear\".test.KundenverwaltungListener.\"env/de.swe2.kundenverwaltung.service.KundenverwaltungListener/mailer\".jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.8","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Dao.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.ValidationService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Kundenverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Artikelverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.FileStore.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.RolesService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.BestellverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.PasswordService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".jndiDependencyService","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Bestellverwaltung.START"]}
> 11:12:08,468 INFO  [org.jboss.jpa] (MSC service thread 1-1) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:12:08,470 INFO  [org.jboss.weld] (MSC service thread 1-1) Stopping weld service
> 2) I tried
> @Resource
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:09:20,085 INFO  [org.jboss.as.server.controller] (pool-1-thread-46) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START"]}
> 11:09:20,094 INFO  [org.jboss.jpa] (MSC service thread 1-2) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:09:20,098 INFO  [org.jboss.weld] (MSC service thread 1-2) Stopping weld service

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Tue Jul 26 00:33:24 2011
From: jira-events at lists.jboss.org (Cloves Almeida (JIRA))
Date: Tue, 26 Jul 2011 00:33:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-708) Ability to specify
 classloading exceptions to ignore similar to
 scanning-deployers-jboss-beans.xml
In-Reply-To: <76119589.26581.1304391198359.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1548228718.81303.1311654804218.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616391#comment-12616391 ] 

Cloves Almeida commented on AS7-708:
------------------------------------

I agree it's a bad practice, but it's not for forbidden by any spec. I agree that a compromise is to continue the deployment and WARN the developer.

> Ability to specify classloading exceptions to ignore similar to scanning-deployers-jboss-beans.xml
> --------------------------------------------------------------------------------------------------
>
>                 Key: AS7-708
>                 URL: https://issues.jboss.org/browse/AS7-708
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: Jason Porter
>            Assignee: David Lloyd
>         Attachments: catch-demo.war
>
>
> We need to be able to specify exceptions to ignore during classpath scanning. This was available in AS6, we need it in AS7, or something similar. Please see https://issues.jboss.org/browse/SEAMFORGE-156

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 00:47:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 26 Jul 2011 00:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-799) Wrong Classloader
 Used When Deserializing Persisted Sessions
In-Reply-To: <468185631.5268.1305634621553.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2055222250.81318.1311655643949.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616394#comment-12616394 ] 

Stuart Douglas commented on AS7-799:
------------------------------------

The problem is that with JBoss modules there may not actually exist a single class loader that can see all the classes that are needed to de-serialize the object graph. 

Say we have 3 modules ModuleA, ModuleB and ModuleC, where ModuleA depends on ModuleB, and ModuleB depends on ModuleC (so ModuleA cannot see ModuleC's classes).

If you then have a class from ModuleA that references a class from ModuleB that references a class from ModuleC there is no class loader availible that can see all three classes. 

JBoss marshaling gets around this by encoding the module that the class belongs to into the serialized form.

> Wrong Classloader Used When Deserializing Persisted Sessions
> ------------------------------------------------------------
>
>                 Key: AS7-799
>                 URL: https://issues.jboss.org/browse/AS7-799
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Beta3
>            Reporter: Benjamin Browning
>            Assignee: Remy Maucherat
>
> The org.jboss.as.web:main module's classloader is being used when deserializing persisted sessions instead of the deployment's classloader. This leads to errors like the one below when any classes are referenced in the session that aren't in the dependency list of org/jboss/as/web/main/module.xml.
> 21:02:50,824 ERROR [org.apache.catalina.session.ManagerBase] (MSC service thread 1-1) ClassNotFoundException while loading persisted sessions: java.lang.ClassNotFoundException: org.jboss.weld.context.conversation.ConversationIdGenerator from [Module "org.jboss.as.web:main" from local module loader @32b0bad7 (roots: /Users/bbrowning/src/torquebox/integration-tests/target/integ-dist/jboss/modules)]: java.lang.ClassNotFoundException: org.jboss.weld.context.conversation.ConversationIdGenerator from [Module "org.jboss.as.web:main" from local module loader @32b0bad7 (roots: /Users/bbrowning/src/torquebox/integration-tests/target/integ-dist/jboss/modules)]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:184) [:1.0.0.Beta17]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:357) [:1.0.0.Beta17]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:329) [:1.0.0.Beta17]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:306) [:1.0.0.Beta17]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:100) [:1.0.0.Beta17]
> at java.lang.Class.forName0(Native Method) [:1.6.0_24]
> at java.lang.Class.forName(Class.java:247) [:1.6.0_24]
> at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:603) [:1.6.0_24]
> at org.apache.catalina.util.CustomObjectInputStream.resolveClass(CustomObjectInputStream.java:78) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1574) [:1.6.0_24]
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495) [:1.6.0_24]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731) [:1.6.0_24]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) [:1.6.0_24]
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) [:1.6.0_24]
> at org.apache.catalina.session.StandardSession.readObject(StandardSession.java:1429) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
> at org.apache.catalina.session.StandardSession.readObjectData(StandardSession.java:934) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
> at org.apache.catalina.session.StandardManager.doLoad(StandardManager.java:395) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
> at org.apache.catalina.session.StandardManager.load(StandardManager.java:322) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
> at org.apache.catalina.session.StandardManager.start(StandardManager.java:633) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
> at org.apache.catalina.core.ContainerBase.setManager(ContainerBase.java:459) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:3776) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
> at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:61) [jboss-as-web-7.0.0.Beta3.jar:7.0.0.Beta3]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675)
> 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]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 01:29:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 26 Jul 2011 01:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1398) Stop using annotation
 literals in EJB configuration
Message-ID: <1098783961.81343.1311658163623.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Stop using annotation literals in EJB configuration 
----------------------------------------------------

                 Key: AS7-1398
                 URL: https://issues.jboss.org/browse/AS7-1398
             Project: Application Server 7
          Issue Type: Feature Request
          Components: EJB
    Affects Versions: 7.0.0.Final
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas


We should not be using annotation literals internally to store configuration data.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 01:33:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 26 Jul 2011 01:33:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1373) Setting EJB's
 InjectionTarget does not work
In-Reply-To: <816583500.75986.1311336683637.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <523898024.81347.1311658403692.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved AS7-1373.
---------------------------------

    Resolution: Done


> Setting EJB's InjectionTarget does not work
> -------------------------------------------
>
>                 Key: AS7-1373
>                 URL: https://issues.jboss.org/browse/AS7-1373
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 7.0.0.Final
>            Reporter: Jozef Hartinger
>            Assignee: Stuart Douglas
>            Priority: Blocker
>             Fix For: 7.0.1.Final
>
>
> Having an EJB
> {code}
> @Singleton
> public class Bus {
>     private boolean initialized = false;
>     public boolean isInitialized() {
>         return initialized;
>     }
>     public void setInitialized(boolean initialized) {
>         this.initialized = initialized;
>     }
> }
> {code}
> and a CDI extension that wraps EJB's InjectionTarget
> {code}
> public class WrappingExtension implements Extension {
>     public void wrapInjectionTarget(@Observes ProcessInjectionTarget<Bus> event)
>     {
>         final InjectionTarget<Bus> injectionTarget = event.getInjectionTarget();
>         event.setInjectionTarget(new ForwardingInjectionTarget<Bus>() {
>             @Override
>             public void inject(Bus instance, CreationalContext<Bus> ctx) {
>                 super.inject(instance, ctx);
>                 instance.setInitialized(true);
>             }
>             @Override
>             public InjectionTarget<Bus> getDelegate() {
>                 return injectionTarget;
>             }
>         });
>     }
> }
> {code}
> the InjectionTarget implementation is never invoked. When the Bus bean is changed to a CDI bean (@Singleton annotation is removed), the InjectionTarget implementation is invoked as expected.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 01:58:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 26 Jul 2011 01:58:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1349) JAX-RS sub resources
	broken
In-Reply-To: <205889520.68555.1311160943630.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <255524965.81358.1311659903709.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved AS7-1349.
---------------------------------

    Resolution: Done


> JAX-RS sub resources broken
> ---------------------------
>
>                 Key: AS7-1349
>                 URL: https://issues.jboss.org/browse/AS7-1349
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>            Reporter: Jozef Hartinger
>            Assignee: Stuart Douglas
>            Priority: Critical
>             Fix For: 7.0.1.Final
>
>
> Having a root resource class
> @Path("person")
> public class PeopleResource {
>     @Path("{name}")
>     public PersonResource findPerson(@PathParam("name") String name)
>     {
>         return new PersonResource(name);
>     }
> }
> and a sub resource class
> public class PersonResource {
>     private String name;
>     public PersonResource(String name) {
>         this.name = name;
>     }
>     @GET
>     public String getName()
>     {
>         return name;
>     }
>     
>     @GET
>     @Path("/address")
>     public String getClassName()
>     {
>         return name + "'s address is unknown.";
>     }
> }
> The application fails with the following exception. Seems like during scanning the subresource is identified as a root resource (although it is not a root resource). Subsequently, RESTEasy's validation fails.
> javax.servlet.ServletException: Servlet.init() for servlet org.jboss.resteasy.cdi.test.MyApplication threw exception
> 	org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
> 	org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
> 	org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> 	org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667)
> 	org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951)
> 	java.lang.Thread.run(Thread.java:662)
> root cause
> java.lang.RuntimeException: Class is not a root resource.  It, or one of its interfaces must be annotated with @Path: org.jboss.resteasy.cdi.test.Subresource implements:  java.io.Serializable
> 	org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:104)
> 	org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:83)
> 	org.jboss.resteasy.core.ResourceMethodRegistry.addPerRequestResource(ResourceMethodRegistry.java:72)
> 	org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:367)
> 	org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:225)
> 	org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:67)
> 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
> 	org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
> 	org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
> 	org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
> 	org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667)
> 	org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951)
> 	java.lang.Thread.run(Thread.java:662)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 02:04:23 2011
From: jira-events at lists.jboss.org (Terence Gamboa (JIRA))
Date: Tue, 26 Jul 2011 02:04:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-630) Can't process JSF TLD
In-Reply-To: <835417069.28548.1294000518112.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1302859933.81363.1311660263791.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616396#comment-12616396 ] 

Terence Gamboa commented on AS7-630:
------------------------------------

I am acutally getting a similar error for Spring Surf's surf.tld. I checked the file and the end of each line has the carriage return and line feeds with no extra spaces. What exactly does trimming it entail?

> Can't process JSF TLD
> ---------------------
>
>                 Key: AS7-630
>                 URL: https://issues.jboss.org/browse/AS7-630
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Alpha1
>            Reporter: Stan Silvert
>            Assignee: Remy Maucherat
>         Attachments: mojarra2.0-bundled.war
>
>
> WAR to reproduce is attached.
> 15:32:07,764 ERROR [org.jboss.as.server.deployment] (pool-3-thread-1) Caught exc
> eption handling update (param is 10cd5140-b773-49da-97ab-0fb055b56141): java.lan
> g.RuntimeException: Failed to process deployment chain.
>         at org.jboss.as.model.ServerDeploymentStartStopHandler.activate(ServerDe
> ploymentStartStopHandler.java:203)
>         at org.jboss.as.model.ServerDeploymentStartStopHandler.deploy(ServerDepl
> oymentStartStopHandler.java:87)
>         at org.jboss.as.model.ServerDeploymentStartStopHandler.deploy(ServerDepl
> oymentStartStopHandler.java:71)
>         at org.jboss.as.model.ServerDeploymentStartStopHandler.redeploy(ServerDe
> ploymentStartStopHandler.java:117)
>         at org.jboss.as.model.ServerModelDeploymentFullReplaceUpdate.applyUpdate
> (ServerModelDeploymentFullReplaceUpdate.java:68)
>         at org.jboss.as.server.mgmt.ServerUpdateController$ServerModelUpdateTupl
> e.applyUpdate(ServerUpdateController.java:430)
>         at org.jboss.as.server.mgmt.ServerUpdateController$ServerModelUpdateTupl
> e.access$200(ServerUpdateController.java:400)
>         at org.jboss.as.server.mgmt.ServerUpdateController.applyUpdates(ServerUp
> dateController.java:189)
>         at org.jboss.as.server.mgmt.ServerUpdateController.executeUpdates(Server
> UpdateController.java:142)
>         at org.jboss.as.server.mgmt.deployment.ServerDeploymentManagerImpl$2.run
> (ServerDeploymentManagerImpl.java:218)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec
> utor.java:886) [:1.6.0_18]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
> .java:908) [:1.6.0_18]
>         at java.lang.Thread.run(Thread.java:619) [:1.6.0_18]
> Caused by: org.jboss.as.deployment.unit.DeploymentUnitProcessingException: Faile
> d to parse "/C:/projects/as7trunk/jboss-as/build/target/jboss-7.0.0.Alpha2/bin/c
> ontent/mojarra2.0-bundled.war/WEB-INF/lib/jsf-impl-2.0.3-b05.jar/META-INF/html_b
> asic.tld"
>         at org.jboss.as.web.deployment.TldParsingDeploymentProcessor.parseTLD(Tl
> dParsingDeploymentProcessor.java:118)
>         at org.jboss.as.web.deployment.TldParsingDeploymentProcessor.processTlds
> (TldParsingDeploymentProcessor.java:97)
>         at org.jboss.as.web.deployment.TldParsingDeploymentProcessor.processDepl
> oyment(TldParsingDeploymentProcessor.java:77)
>         at org.jboss.as.deployment.chain.DeploymentChainImpl.processDeployment(D
> eploymentChainImpl.java:50)
>         at org.jboss.as.model.ServerDeploymentStartStopHandler.activate(ServerDe
> ploymentStartStopHandler.java:201)
>         ... 12 more
> Caused by: java.lang.IllegalArgumentException: No enum const class org.jboss.met
> adata.web.spec.BodyContentType.
>             JSP
>         at java.lang.Enum.valueOf(Enum.java:196) [:1.6.0_18]
>         at org.jboss.metadata.web.spec.BodyContentType.valueOf(BodyContentType.j
> ava:32)
>         at org.jboss.as.metadata.parser.jsp.TagMetaDataParser.parse(TagMetaDataP
> arser.java:111)
>         at org.jboss.as.metadata.parser.jsp.TldMetaDataParser.parse(TldMetaDataP
> arser.java:200)
>         at org.jboss.as.web.deployment.TldParsingDeploymentProcessor.parseTLD(Tl
> dParsingDeploymentProcessor.java:116)
>         ... 16 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 02:42:23 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 26 Jul 2011 02:42:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMESSAGING-1889) Duplicate
 messages are produced during cluster failover when a cluster node is
 shutdown
In-Reply-To: <1376159458.63243.1311086964843.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <873905827.81417.1311662543903.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao resolved JBMESSAGING-1889.
---------------------------------------

    Resolution: Done


> Duplicate messages are produced during cluster failover when a cluster node is shutdown
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1889
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1889
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP14, 1.4.8.SP1, 1.4.8.SP2
>         Environment: JBoss EAP 5.1.1
>            Reporter: Tom Ross
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>         Attachments: DistributedQueueExample.java
>
>
> The scenarion describes a set-up consisting of JBoss cluster and a stand alone JBoss instance hosting a MDB. 
> During the test the master node of the JBoss cluster is shutdown using CTRL/C or shutdown.sh script.
> The following is a description of the events that hava happened that lead to duplicate messages.
> - Message is delivered to a MDB from node-1 of the cluster to a MDB in a transaction. The transaction prepare has failed because the server peer of node-1 is shutting down.
> - Message is rolled back and received again in another transaction. This happens at the client side only. Then the transaction is committed on node-2 as the client has failed over to node-2 of the cluster.
> - Meanwhile the fact that node-1 is shutting down causes server side failover to happen and the message is failed over to node-2.
> - node-2 redelivers the message to the MDB in a separate transaction and committs.
> So the message is received twice.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 02:42:24 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 26 Jul 2011 02:42:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1889) Duplicate
 messages are produced during cluster failover when a cluster node is
 shutdown
In-Reply-To: <1376159458.63243.1311086964843.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1186351820.81425.1311662544080.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao closed JBMESSAGING-1889.
-------------------------------------



> Duplicate messages are produced during cluster failover when a cluster node is shutdown
> ---------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1889
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1889
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0.SP3.CP14, 1.4.8.SP1, 1.4.8.SP2
>         Environment: JBoss EAP 5.1.1
>            Reporter: Tom Ross
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>         Attachments: DistributedQueueExample.java
>
>
> The scenarion describes a set-up consisting of JBoss cluster and a stand alone JBoss instance hosting a MDB. 
> During the test the master node of the JBoss cluster is shutdown using CTRL/C or shutdown.sh script.
> The following is a description of the events that hava happened that lead to duplicate messages.
> - Message is delivered to a MDB from node-1 of the cluster to a MDB in a transaction. The transaction prepare has failed because the server peer of node-1 is shutting down.
> - Message is rolled back and received again in another transaction. This happens at the client side only. Then the transaction is committed on node-2 as the client has failed over to node-2 of the cluster.
> - Meanwhile the fact that node-1 is shutting down causes server side failover to happen and the message is failed over to node-2.
> - node-2 redelivers the message to the MDB in a separate transaction and committs.
> So the message is received twice.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 02:47:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 26 Jul 2011 02:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1017) Deployment does not
 fail on missing Extension-List entry
In-Reply-To: <1865740743.1083.1308076709419.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <225662335.81427.1311662843766.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved AS7-1017.
---------------------------------

    Resolution: Rejected


I am not going to change this. IMHO The current warn and ignore behaviour is much more friendly than an outright deployment failure. Changing this could lead to situations where devleopers have to break open third party archives to fix extensions list entries which is a massive PITA.  

> Deployment does not fail on missing Extension-List entry
> --------------------------------------------------------
>
>                 Key: AS7-1017
>                 URL: https://issues.jboss.org/browse/AS7-1017
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Server
>            Reporter: Carlo de Wolf
>            Assignee: Stuart Douglas
>
> EE 8.2.2 Installed Libraries
> bq. The deployment tool is required to check such dependency information and reject the deployment of any component for which the dependency can not be met.
> It'll lead to trouble further down the line anyway where classes can not be found.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 03:11:23 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 26 Jul 2011 03:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1890) Recovery
 configuration in a cluster is too burdensome
In-Reply-To: <1818771781.66923.1311109463768.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1256440086.81491.1311664283751.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBMESSAGING-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616403#comment-12616403 ] 

Yong Hao Gao commented on JBMESSAGING-1890:
-------------------------------------------

Hi Justin,

I think the simple solution is to add a flag that controls whether or not to failover the transactions.

Howard


> Recovery configuration in a cluster is too burdensome
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-1890
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1890
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: JMS Clustering
>    Affects Versions: 1.4.8.SP1
>            Reporter: Justin Bertram
>            Assignee: Yong Hao Gao
>
> The recovery configuration describe on http://community.jboss.org/wiki/Non-serializableXAResourceErrorFromJBossMessagingJBM-ClusteredSetup is too burdensome, especially for large clusters.  When a new node is added to the cluster then *every* node in the cluster needs a configuration change.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 03:14:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 26 Jul 2011 03:14:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-9422) Minimal server
 fails to start due to CNFE
In-Reply-To: <1168294145.81133.1311636443614.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1860948115.81494.1311664463622.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBAS-9422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved JBAS-9422.
--------------------------------

    Resolution: Done


Fixed in r111832.

> Minimal server fails to start due to CNFE
> -----------------------------------------
>
>                 Key: JBAS-9422
>                 URL: https://issues.jboss.org/browse/JBAS-9422
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Shelly McGowan
>            Assignee: jaikiran pai
>             Fix For: 6.1.0
>
>         Attachments: boot.log
>
>
> Failed to boot JBoss:
> java.lang.Exception: Encountered exception in server startup
> 	at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.bootstrapMcAndDescriptors(AbstractMCServerBase.java:350)
> 	at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.doStart(AbstractMCServerBase.java:282)
> 	at org.jboss.bootstrap.impl.as.server.AbstractJBossASServerBase.doStart(AbstractJBossASServerBase.java:381)
> 	at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:413)
> 	at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.IllegalStateException: Incompletely deployed:
> DEPLOYMENTS IN ERROR:
>   Deployment "DeclaredStructure" is in error due to: java.lang.ClassNotFoundException: org.jboss.deployment.ExplicitDeclaredStructure
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.internalValidate(AbstractKernelDeployer.java:278)
> 	at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.validate(AbstractKernelDeployer.java:174)
> 	at org.jboss.bootstrap.impl.mc.server.AbstractMCServerBase.bootstrapMcAndDescriptors(AbstractMCServerBase.java:339)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 03:23:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 26 Jul 2011 03:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1296) JBREM00200: Remote
 connection failed
In-Reply-To: <1442430573.56217.1310730983622.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <834307491.81506.1311665003721.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616405#comment-12616405 ] 

jaikiran pai commented on AS7-1296:
-----------------------------------

You don't need Maven to run JBoss AS binary.



> JBREM00200: Remote connection failed
> ------------------------------------
>
>                 Key: AS7-1296
>                 URL: https://issues.jboss.org/browse/AS7-1296
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Final
>            Reporter: Gary Quinn
>
> Downloaded JBoss and followed the "Installing and starting JBoss AS on Linux, Unix or Mac OS X". started the standalone server (jboss-as-7.0.0.Final/bin/standalone.sh)
> Server starts but keep logging the following error: 13:57:52,026 ERROR [org.jboss.remoting.remote] (XNIO NIO Read 1) JBREM00200: Remote connection failed: java.io.IOException: Received an invalid message length of 1195725856

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 03:23:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 26 Jul 2011 03:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1296) JBREM00200: Remote
 connection failed
In-Reply-To: <1442430573.56217.1310730983622.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <575586550.81509.1311665003791.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated AS7-1296:
------------------------------

       Assignee: David Lloyd
    Component/s: Remoting


This appears to be something in Remoting. Assigning to appropriate component

> JBREM00200: Remote connection failed
> ------------------------------------
>
>                 Key: AS7-1296
>                 URL: https://issues.jboss.org/browse/AS7-1296
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Remoting
>    Affects Versions: 7.0.0.Final
>            Reporter: Gary Quinn
>            Assignee: David Lloyd
>
> Downloaded JBoss and followed the "Installing and starting JBoss AS on Linux, Unix or Mac OS X". started the standalone server (jboss-as-7.0.0.Final/bin/standalone.sh)
> Server starts but keep logging the following error: 13:57:52,026 ERROR [org.jboss.remoting.remote] (XNIO NIO Read 1) JBREM00200: Remote connection failed: java.io.IOException: Received an invalid message length of 1195725856

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 03:29:24 2011
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Tue, 26 Jul 2011 03:29:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1296) JBREM00200: Remote
 connection failed
In-Reply-To: <1442430573.56217.1310730983622.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <411467167.81526.1311665364941.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

SBS JIRA Integration updated AS7-1296:
--------------------------------------

    Forum Reference: http://community.jboss.org/message/617349#617349


> JBREM00200: Remote connection failed
> ------------------------------------
>
>                 Key: AS7-1296
>                 URL: https://issues.jboss.org/browse/AS7-1296
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Remoting
>    Affects Versions: 7.0.0.Final
>            Reporter: Gary Quinn
>            Assignee: David Lloyd
>
> Downloaded JBoss and followed the "Installing and starting JBoss AS on Linux, Unix or Mac OS X". started the standalone server (jboss-as-7.0.0.Final/bin/standalone.sh)
> Server starts but keep logging the following error: 13:57:52,026 ERROR [org.jboss.remoting.remote] (XNIO NIO Read 1) JBREM00200: Remote connection failed: java.io.IOException: Received an invalid message length of 1195725856

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 04:59:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 26 Jul 2011 04:59:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1399) Domain Controller
 hangs when being shutdown
Message-ID: <1968846097.81710.1311670763810.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Domain Controller hangs when being shutdown
-------------------------------------------

                 Key: AS7-1399
                 URL: https://issues.jboss.org/browse/AS7-1399
             Project: Application Server 7
          Issue Type: Bug
          Components: Domain Management
            Reporter: Heiko Braun
            Assignee: Jason Greene
            Priority: Critical
             Fix For: 7.0.1.Final


See https://gist.github.com/1106319

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 05:01:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 26 Jul 2011 05:01:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1399) Domain Controller
 hangs when being shutdown
In-Reply-To: <1968846097.81710.1311670763810.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1888626187.81715.1311670883686.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616418#comment-12616418 ] 

Heiko Braun commented on AS7-1399:
----------------------------------

rev fc36f789333dbc5524530ad6df8b0cbf4d8a18da

> Domain Controller hangs when being shutdown
> -------------------------------------------
>
>                 Key: AS7-1399
>                 URL: https://issues.jboss.org/browse/AS7-1399
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Jason Greene
>            Priority: Critical
>             Fix For: 7.0.1.Final
>
>
> See https://gist.github.com/1106319

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 07:03:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 26 Jul 2011 07:03:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1399) Domain Controller
 hangs when being shutdown
In-Reply-To: <1968846097.81710.1311670763810.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <96757129.82023.1311678203685.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616460#comment-12616460 ] 

Heiko Braun commented on AS7-1399:
----------------------------------

the domain has a resource adapter installed. maybe that's causing the problem. se the attachment

> Domain Controller hangs when being shutdown
> -------------------------------------------
>
>                 Key: AS7-1399
>                 URL: https://issues.jboss.org/browse/AS7-1399
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Jason Greene
>            Priority: Critical
>             Fix For: 7.0.1.Final
>
>         Attachments: ra-config.xml, xmpp-ra.rar
>
>
> See https://gist.github.com/1106319

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 07:03:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 26 Jul 2011 07:03:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1399) Domain Controller
 hangs when being shutdown
In-Reply-To: <1968846097.81710.1311670763810.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1310434964.82029.1311678203812.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated AS7-1399:
-----------------------------

    Attachment: xmpp-ra.rar
                ra-config.xml


> Domain Controller hangs when being shutdown
> -------------------------------------------
>
>                 Key: AS7-1399
>                 URL: https://issues.jboss.org/browse/AS7-1399
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Jason Greene
>            Priority: Critical
>             Fix For: 7.0.1.Final
>
>         Attachments: ra-config.xml, xmpp-ra.rar
>
>
> See https://gist.github.com/1106319

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 07:07:24 2011
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Tue, 26 Jul 2011 07:07:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1321) Upgrade to
 JBossWS-CXF 4.0.0.Beta3
In-Reply-To: <92893259.61080.1311015870101.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1562827648.82041.1311678444064.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano resolved AS7-1321.
----------------------------------

    Resolution: Done


> Upgrade to JBossWS-CXF 4.0.0.Beta3
> ----------------------------------
>
>                 Key: AS7-1321
>                 URL: https://issues.jboss.org/browse/AS7-1321
>             Project: Application Server 7
>          Issue Type: Component  Upgrade
>          Components: Web Services
>            Reporter: Alessio Soldano
>            Assignee: Alessio Soldano
>             Fix For: 7.0.1.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 07:39:23 2011
From: jira-events at lists.jboss.org (Pavel Sknar (JIRA))
Date: Tue, 26 Jul 2011 07:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3155) Bug with default
 properties in KnowledgeStoreServiceImpl
Message-ID: <678863619.82084.1311680363658.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Bug with default properties in KnowledgeStoreServiceImpl
--------------------------------------------------------

                 Key: JBRULES-3155
                 URL: https://issues.jboss.org/browse/JBRULES-3155
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.2.0.Final
            Reporter: Pavel Sknar
            Assignee: Mark Proctor
            Priority: Critical


Method setDefaultImplementations() set default properties in configProps (class KnowledgeStoreServiceImpl). mergeConfig() execute after specific properties loaded to configuration. This overlaps specific properties.

[17:08] <pavlz> hi 
[17:09] <pavlz> I have bug for you
[17:09] <Rikkola> :(
[17:10] <pavlz> Problem with KnowledgeStoreServiceImpl
[17:10] <pavlz> in org.drools.persistence.jpa
[17:12] <pavlz> default properties merged first in config (in ChainedProperties: this.props.add( 0, properties ))
[17:14] <pavlz> and this overlaps specific properties
[17:15] <pavlz> drools.commandService, drools.timerService and else
[17:15] <pavlz> I have this bug in 5.2.0.Final
[17:23] <conan> pavlz: do you have a fix?
[17:25] <pavlz> No, I see this now
[17:27] <pavlz> but I think: need to create in ChainedProperties new method "setDefaultProperties"
[17:29] <pavlz> and in SessionConfiguration too, to use this method in KnowledgeStoreServiceImpl.mergeConfig()
[17:30] <pavlz> then default properties loaded later
[17:31] <Rikkola> pavlz: best to make a jira about it
[17:31] <Rikkola> https://issues.jboss.org/browse/JBRULES
[17:31] <pavlz> ok

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 08:05:23 2011
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Tue, 26 Jul 2011 08:05:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1400) Built-in JAX-RS
 providers registered twice
Message-ID: <335005987.82158.1311681923643.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Built-in JAX-RS providers registered twice
------------------------------------------

                 Key: AS7-1400
                 URL: https://issues.jboss.org/browse/AS7-1400
             Project: Application Server 7
          Issue Type: Bug
          Components: Web Services
    Affects Versions: 7.0.0.Final
            Reporter: Jozef Hartinger
            Assignee: Stuart Douglas
             Fix For: 7.0.1.Final


RESTEasy considers every JAX-RS provider listed in a service loader-like to be a built-in provider. RESTEasy take care of loading of these providers early in the startup. Once loaded, these providers are registered with "built-in" flag, which is important to guarantee that any custom provider is given priority over a built-in one at runtime. The registration is handled by the RegisterBuiltin class https://resteasy.svn.sourceforge.net/svnroot/resteasy/trunk/jaxrs/resteasy-jaxrs/src/main/java/org/jboss/resteasy/plugins/providers/RegisterBuiltin.java

However, it seems that AS7 scans resteasy jars for providers and registers the built-in providers again - as application-provided providers. As a result, every built-in provider is registered twice. Once as built-in and once as application-provided provider. This has several consequences. Once of them is that the priority of application-provided providers is not guaranteed any longer.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 08:09:24 2011
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Tue, 26 Jul 2011 08:09:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1400) Built-in JAX-RS
 providers registered twice
In-Reply-To: <335005987.82158.1311681923643.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <588843198.82170.1311682164029.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616474#comment-12616474 ] 

Jozef Hartinger commented on AS7-1400:
--------------------------------------

Testcase https://github.com/jharting/jboss-as/tree/AS7-1400-testcase

> Built-in JAX-RS providers registered twice
> ------------------------------------------
>
>                 Key: AS7-1400
>                 URL: https://issues.jboss.org/browse/AS7-1400
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>            Reporter: Jozef Hartinger
>            Assignee: Stuart Douglas
>             Fix For: 7.0.1.Final
>
>
> RESTEasy considers every JAX-RS provider listed in a service loader-like to be a built-in provider. RESTEasy take care of loading of these providers early in the startup. Once loaded, these providers are registered with "built-in" flag, which is important to guarantee that any custom provider is given priority over a built-in one at runtime. The registration is handled by the RegisterBuiltin class https://resteasy.svn.sourceforge.net/svnroot/resteasy/trunk/jaxrs/resteasy-jaxrs/src/main/java/org/jboss/resteasy/plugins/providers/RegisterBuiltin.java
> However, it seems that AS7 scans resteasy jars for providers and registers the built-in providers again - as application-provided providers. As a result, every built-in provider is registered twice. Once as built-in and once as application-provided provider. This has several consequences. Once of them is that the priority of application-provided providers is not guaranteed any longer.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 08:19:24 2011
From: jira-events at lists.jboss.org (Tom Ross (JIRA))
Date: Tue, 26 Jul 2011 08:19:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1891) Null point
 exception while committing a transaction
Message-ID: <749619232.82202.1311682764248.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Null point exception while committing a transaction
---------------------------------------------------

                 Key: JBMESSAGING-1891
                 URL: https://issues.jboss.org/browse/JBMESSAGING-1891
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core
    Affects Versions: 1.4.8.SP1
         Environment: JBoss EAP 5.1.1
            Reporter: Tom Ross
            Assignee: Yong Hao Gao


The following exception gets throw when committing a transaction:

12:02:53,098 WARN  [loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.commitexception] [com.arjuna.ats.internal.jta.resources.arjunacore.commitexception] XAResourceRecord.topLevelCommit caught: java.lang.NullPointerException
java.lang.NullPointerException
        at org.jboss.jms.tx.ResourceManager.commit(ResourceManager.java:375)
        at org.jboss.jms.tx.MessagingXAResource.commit(MessagingXAResource.java:255)
        at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.commit(MessagingXAResourceWrapper.java:126)
        at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelCommit(XAResourceRecord.java:568)
        at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:3155)
        at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:3070)
        at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:2131)
        at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:85)
        at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:181)
        at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:294)
        at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:128)
        at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:799)
        at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:412)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 08:21:23 2011
From: jira-events at lists.jboss.org (Tom Ross (JIRA))
Date: Tue, 26 Jul 2011 08:21:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-1891)
 java.lang.NullPointerException while committing a transaction
In-Reply-To: <749619232.82202.1311682764248.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <494591792.82206.1311682883667.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Ross updated JBMESSAGING-1891:
----------------------------------

        Summary: java.lang.NullPointerException while committing a transaction  (was: Null point exception while committing a transaction)
    Description: 
The following exception gets thrown when committing a transaction:

12:02:53,098 WARN  [loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.commitexception] [com.arjuna.ats.internal.jta.resources.arjunacore.commitexception] XAResourceRecord.topLevelCommit caught: java.lang.NullPointerException
java.lang.NullPointerException
        at org.jboss.jms.tx.ResourceManager.commit(ResourceManager.java:375)
        at org.jboss.jms.tx.MessagingXAResource.commit(MessagingXAResource.java:255)
        at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.commit(MessagingXAResourceWrapper.java:126)
        at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelCommit(XAResourceRecord.java:568)
        at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:3155)
        at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:3070)
        at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:2131)
        at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:85)
        at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:181)
        at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:294)
        at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:128)
        at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:799)
        at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:412)

  was:
The following exception gets throw when committing a transaction:

12:02:53,098 WARN  [loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.commitexception] [com.arjuna.ats.internal.jta.resources.arjunacore.commitexception] XAResourceRecord.topLevelCommit caught: java.lang.NullPointerException
java.lang.NullPointerException
        at org.jboss.jms.tx.ResourceManager.commit(ResourceManager.java:375)
        at org.jboss.jms.tx.MessagingXAResource.commit(MessagingXAResource.java:255)
        at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.commit(MessagingXAResourceWrapper.java:126)
        at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelCommit(XAResourceRecord.java:568)
        at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:3155)
        at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:3070)
        at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:2131)
        at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:85)
        at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:181)
        at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:294)
        at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:128)
        at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:799)
        at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:412)



> java.lang.NullPointerException while committing a transaction
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1891
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1891
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.8.SP1
>         Environment: JBoss EAP 5.1.1
>            Reporter: Tom Ross
>            Assignee: Yong Hao Gao
>
> The following exception gets thrown when committing a transaction:
> 12:02:53,098 WARN  [loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.commitexception] [com.arjuna.ats.internal.jta.resources.arjunacore.commitexception] XAResourceRecord.topLevelCommit caught: java.lang.NullPointerException
> java.lang.NullPointerException
>         at org.jboss.jms.tx.ResourceManager.commit(ResourceManager.java:375)
>         at org.jboss.jms.tx.MessagingXAResource.commit(MessagingXAResource.java:255)
>         at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.commit(MessagingXAResourceWrapper.java:126)
>         at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelCommit(XAResourceRecord.java:568)
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:3155)
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:3070)
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:2131)
>         at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:85)
>         at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:181)
>         at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:294)
>         at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:128)
>         at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:799)
>         at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:412)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 08:29:23 2011
From: jira-events at lists.jboss.org (Tom Ross (JIRA))
Date: Tue, 26 Jul 2011 08:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1891)
 java.lang.NullPointerException while committing a transaction
In-Reply-To: <749619232.82202.1311682764248.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1501476368.82217.1311683363744.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Ross reassigned JBMESSAGING-1891:
-------------------------------------

    Assignee: Tom Ross  (was: Yong Hao Gao)


> java.lang.NullPointerException while committing a transaction
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-1891
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1891
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.8.SP1
>         Environment: JBoss EAP 5.1.1
>            Reporter: Tom Ross
>            Assignee: Tom Ross
>
> The following exception gets thrown when committing a transaction:
> 12:02:53,098 WARN  [loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.commitexception] [com.arjuna.ats.internal.jta.resources.arjunacore.commitexception] XAResourceRecord.topLevelCommit caught: java.lang.NullPointerException
> java.lang.NullPointerException
>         at org.jboss.jms.tx.ResourceManager.commit(ResourceManager.java:375)
>         at org.jboss.jms.tx.MessagingXAResource.commit(MessagingXAResource.java:255)
>         at org.jboss.jms.server.recovery.MessagingXAResourceWrapper.commit(MessagingXAResourceWrapper.java:126)
>         at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelCommit(XAResourceRecord.java:568)
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:3155)
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(BasicAction.java:3070)
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Commit(BasicAction.java:2131)
>         at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.replayPhase2(RecoverAtomicAction.java:85)
>         at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecoveryModule.java:181)
>         at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.processTransactionsStatus(AtomicActionRecoveryModule.java:294)
>         at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.periodicWorkSecondPass(AtomicActionRecoveryModule.java:128)
>         at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:799)
>         at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:412)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 08:34:23 2011
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 26 Jul 2011 08:34:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1401) Domain Managent -
 Support for client choosing auth mechanism
Message-ID: <1361747851.82223.1311683663679.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Domain Managent - Support for client choosing auth mechanism
------------------------------------------------------------

                 Key: AS7-1401
                 URL: https://issues.jboss.org/browse/AS7-1401
             Project: Application Server 7
          Issue Type: Task
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 7.1.0.Beta1


Consideration is needed first as there are potential risks - however we should look at what it will take to allow clients to choose from list of auth mechansisms.

AS7-1372 is to look at adding Kerberos support, however this can mean all clients need to also support it so we may need to allow some clients to fallback to a username/password based mechanism.

The authorization scheme still needs further consideration however it is anticipated that the authentication mechansism will also be taken into account, this could mean that for clients that have chosen username / password auth their capabilities are restricted.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 08:42:24 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 26 Jul 2011 08:42:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1402) domain-preview.xml
 bootstrap errors
Message-ID: <640583748.82260.1311684144331.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

domain-preview.xml bootstrap errors
-----------------------------------

                 Key: AS7-1402
                 URL: https://issues.jboss.org/browse/AS7-1402
             Project: Application Server 7
          Issue Type: Bug
          Components: JMS
            Reporter: Heiko Braun
            Assignee: Clebert Suconic



The serves throws these errors when booting the preview.xml:
{noformat}

[Server:server-one] 14:37:20,714 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.messaging.jms.connection-factory.RemoteConnectionFactory: org.jboss.msc.service.StartException in service jboss.messaging.jms.connection-factory.RemoteConnectionFactory: failed to create connection-factory
[Server:server-one] 	at org.jboss.as.messaging.jms.ConnectionFactoryService.start(ConnectionFactoryService.java:83)
[Server:server-one] 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
[Server:server-one] 	at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
[Server:server-one] 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
[Server:server-one] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
[Server:server-one] 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
[Server:server-one] Caused by: HornetQException[errorCode=104 message=Connector 'netty' not found on the main configuration file]
[Server:server-one] 	at org.hornetq.jms.server.impl.JMSServerManagerImpl.internalCreateCFPOJO(JMSServerManagerImpl.java:1174)
{noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 08:42:24 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 26 Jul 2011 08:42:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1402) domain-preview.xml
 bootstrap errors
In-Reply-To: <640583748.82260.1311684144331.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <883746431.82268.1311684144722.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated AS7-1402:
-----------------------------

    Fix Version/s: 7.0.1.Final
      Description: 
The serves throws these errors when booting the preview.xml:
{noformat}

[Server:server-one] 14:37:20,714 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.messaging.jms.connection-factory.RemoteConnectionFactory: org.jboss.msc.service.StartException in service jboss.messaging.jms.connection-factory.RemoteConnectionFactory: failed to create connection-factory
[Server:server-one] 	at org.jboss.as.messaging.jms.ConnectionFactoryService.start(ConnectionFactoryService.java:83)
[Server:server-one] 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
[Server:server-one] 	at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
[Server:server-one] 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
[Server:server-one] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
[Server:server-one] 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
[Server:server-one] Caused by: HornetQException[errorCode=104 message=Connector 'netty' not found on the main configuration file]
[Server:server-one] 	at org.hornetq.jms.server.impl.JMSServerManagerImpl.internalCreateCFPOJO(JMSServerManagerImpl.java:1174)
{noformat}

  was:

The serves throws these errors when booting the preview.xml:
{noformat}

[Server:server-one] 14:37:20,714 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.messaging.jms.connection-factory.RemoteConnectionFactory: org.jboss.msc.service.StartException in service jboss.messaging.jms.connection-factory.RemoteConnectionFactory: failed to create connection-factory
[Server:server-one] 	at org.jboss.as.messaging.jms.ConnectionFactoryService.start(ConnectionFactoryService.java:83)
[Server:server-one] 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
[Server:server-one] 	at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
[Server:server-one] 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
[Server:server-one] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
[Server:server-one] 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
[Server:server-one] Caused by: HornetQException[errorCode=104 message=Connector 'netty' not found on the main configuration file]
[Server:server-one] 	at org.hornetq.jms.server.impl.JMSServerManagerImpl.internalCreateCFPOJO(JMSServerManagerImpl.java:1174)
{noformat}



> domain-preview.xml bootstrap errors
> -----------------------------------
>
>                 Key: AS7-1402
>                 URL: https://issues.jboss.org/browse/AS7-1402
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Heiko Braun
>            Assignee: Clebert Suconic
>             Fix For: 7.0.1.Final
>
>
> The serves throws these errors when booting the preview.xml:
> {noformat}
> [Server:server-one] 14:37:20,714 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.messaging.jms.connection-factory.RemoteConnectionFactory: org.jboss.msc.service.StartException in service jboss.messaging.jms.connection-factory.RemoteConnectionFactory: failed to create connection-factory
> [Server:server-one] 	at org.jboss.as.messaging.jms.ConnectionFactoryService.start(ConnectionFactoryService.java:83)
> [Server:server-one] 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> [Server:server-one] 	at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> [Server:server-one] 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
> [Server:server-one] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
> [Server:server-one] 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> [Server:server-one] Caused by: HornetQException[errorCode=104 message=Connector 'netty' not found on the main configuration file]
> [Server:server-one] 	at org.hornetq.jms.server.impl.JMSServerManagerImpl.internalCreateCFPOJO(JMSServerManagerImpl.java:1174)
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 09:11:23 2011
From: jira-events at lists.jboss.org (Karel Piwko (JIRA))
Date: Tue, 26 Jul 2011 09:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1403) Excluded/Banned
 transitive dependencies for Maven Dependency Resolver are too strict
Message-ID: <415854736.82382.1311685883624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Excluded/Banned transitive dependencies for Maven Dependency Resolver are too strict
------------------------------------------------------------------------------------

                 Key: AS7-1403
                 URL: https://issues.jboss.org/browse/AS7-1403
             Project: Application Server 7
          Issue Type: Bug
          Components: Build System
    Affects Versions: 7.0.0.Final
            Reporter: Karel Piwko
            Assignee: Paul Gier


During 7.0.0.CR1 build, there was a decision to remove transitive dependencies from other projects and exclude/ban them in jboss-as-parent.

This decision has effectively crippled usage of Maven Dependency Resolver, which wasn't used in CR1-date based testsuite, so the change passed silently. 
If user wants to use the ShrinkWrap Dependency Resolver in the AS7 testsuite, he won't get the required transitive dependencies, such as wagon or aether, so the resolver is unusable.

According to disscussion with Vladimir, it would help "to flatten" dependency tree for ShrinkWrap dependency Resolver, however, that's only the part of the solution, the restrictions posed in AS7 parent must be relaxed afterwards.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 09:24:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 26 Jul 2011 09:24:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1301) Update OSGi to be
 compatible with JBoss Modules 1.1 series
In-Reply-To: <970188.57854.1310766324068.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <316040857.82420.1311686663634.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616485#comment-12616485 ] 

Thomas Diesler commented on AS7-1301:
-------------------------------------

How is the client supposed to calculate the system's loader paths? Internally I see JDKPaths being used.

> Update OSGi to be compatible with JBoss Modules 1.1 series
> ----------------------------------------------------------
>
>                 Key: AS7-1301
>                 URL: https://issues.jboss.org/browse/AS7-1301
>             Project: Application Server 7
>          Issue Type: Task
>          Components: OSGi
>            Reporter: David Lloyd
>            Assignee: Thomas Diesler
>             Fix For: 7.1.0.Alpha1
>
>
> JBoss Modules 1.1 has two significant changes.  First, jaxpmodule is eliminated.  Second, the system module is no more - instead there's a dependency type for the system class loader.
> I currently have an updated AS in my http://github.com/dmlloyd/jboss-as/tree/upgrades branch.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 09:26:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 26 Jul 2011 09:26:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-1301) Update
 OSGi to be compatible with JBoss Modules 1.1 series
In-Reply-To: <970188.57854.1310766324068.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <551682789.82424.1311686783722.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616485#comment-12616485 ] 

Thomas Diesler edited comment on AS7-1301 at 7/26/11 9:24 AM:
--------------------------------------------------------------

How is the client supposed to calculate the system loader paths? Internally I see JDKPaths being used.

      was (Author: thomas.diesler):
    How is the client supposed to calculate the system's loader paths? Internally I see JDKPaths being used.
  
> Update OSGi to be compatible with JBoss Modules 1.1 series
> ----------------------------------------------------------
>
>                 Key: AS7-1301
>                 URL: https://issues.jboss.org/browse/AS7-1301
>             Project: Application Server 7
>          Issue Type: Task
>          Components: OSGi
>            Reporter: David Lloyd
>            Assignee: Thomas Diesler
>             Fix For: 7.1.0.Alpha1
>
>
> JBoss Modules 1.1 has two significant changes.  First, jaxpmodule is eliminated.  Second, the system module is no more - instead there's a dependency type for the system class loader.
> I currently have an updated AS in my http://github.com/dmlloyd/jboss-as/tree/upgrades branch.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 09:26:24 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 26 Jul 2011 09:26:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-1301) Update
 OSGi to be compatible with JBoss Modules 1.1 series
In-Reply-To: <970188.57854.1310766324068.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1407235213.82429.1311686784362.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616485#comment-12616485 ] 

Thomas Diesler edited comment on AS7-1301 at 7/26/11 9:26 AM:
--------------------------------------------------------------

How is the client supposed to calculate the system loader paths? Internally I see JDKPaths being used.

{code}
    public static DependencySpec createSystemDependencySpec(final PathFilter importFilter, final PathFilter exportFilter, final Set<String> loaderPaths) {
{code}


      was (Author: thomas.diesler):
    How is the client supposed to calculate the system loader paths? Internally I see JDKPaths being used.
  
> Update OSGi to be compatible with JBoss Modules 1.1 series
> ----------------------------------------------------------
>
>                 Key: AS7-1301
>                 URL: https://issues.jboss.org/browse/AS7-1301
>             Project: Application Server 7
>          Issue Type: Task
>          Components: OSGi
>            Reporter: David Lloyd
>            Assignee: Thomas Diesler
>             Fix For: 7.1.0.Alpha1
>
>
> JBoss Modules 1.1 has two significant changes.  First, jaxpmodule is eliminated.  Second, the system module is no more - instead there's a dependency type for the system class loader.
> I currently have an updated AS in my http://github.com/dmlloyd/jboss-as/tree/upgrades branch.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 09:28:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 26 Jul 2011 09:28:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-1301) Update
 OSGi to be compatible with JBoss Modules 1.1 series
In-Reply-To: <970188.57854.1310766324068.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <567733157.82433.1311686903674.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616485#comment-12616485 ] 

Thomas Diesler edited comment on AS7-1301 at 7/26/11 9:26 AM:
--------------------------------------------------------------

How is the client supposed to calculate the system loader paths? Internally I see JDKPaths being used.

    public static DependencySpec createSystemDependencySpec(final PathFilter importFilter, final PathFilter exportFilter, final Set<String> loaderPaths) {


      was (Author: thomas.diesler):
    How is the client supposed to calculate the system loader paths? Internally I see JDKPaths being used.

{code}
    public static DependencySpec createSystemDependencySpec(final PathFilter importFilter, final PathFilter exportFilter, final Set<String> loaderPaths) {
{code}

  
> Update OSGi to be compatible with JBoss Modules 1.1 series
> ----------------------------------------------------------
>
>                 Key: AS7-1301
>                 URL: https://issues.jboss.org/browse/AS7-1301
>             Project: Application Server 7
>          Issue Type: Task
>          Components: OSGi
>            Reporter: David Lloyd
>            Assignee: Thomas Diesler
>             Fix For: 7.1.0.Alpha1
>
>
> JBoss Modules 1.1 has two significant changes.  First, jaxpmodule is eliminated.  Second, the system module is no more - instead there's a dependency type for the system class loader.
> I currently have an updated AS in my http://github.com/dmlloyd/jboss-as/tree/upgrades branch.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 09:28:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 26 Jul 2011 09:28:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-1301) Update
 OSGi to be compatible with JBoss Modules 1.1 series
In-Reply-To: <970188.57854.1310766324068.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1204370248.82435.1311686903742.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616485#comment-12616485 ] 

Thomas Diesler edited comment on AS7-1301 at 7/26/11 9:26 AM:
--------------------------------------------------------------

How is the client supposed to calculate the system loader paths? Internally I see JDKPaths being used.

    public static DependencySpec createSystemDependencySpec(final PathFilter importFilter, final PathFilter exportFilter, final Set<String> loaderPaths) 


      was (Author: thomas.diesler):
    How is the client supposed to calculate the system loader paths? Internally I see JDKPaths being used.

    public static DependencySpec createSystemDependencySpec(final PathFilter importFilter, final PathFilter exportFilter, final Set<String> loaderPaths) {

  
> Update OSGi to be compatible with JBoss Modules 1.1 series
> ----------------------------------------------------------
>
>                 Key: AS7-1301
>                 URL: https://issues.jboss.org/browse/AS7-1301
>             Project: Application Server 7
>          Issue Type: Task
>          Components: OSGi
>            Reporter: David Lloyd
>            Assignee: Thomas Diesler
>             Fix For: 7.1.0.Alpha1
>
>
> JBoss Modules 1.1 has two significant changes.  First, jaxpmodule is eliminated.  Second, the system module is no more - instead there's a dependency type for the system class loader.
> I currently have an updated AS in my http://github.com/dmlloyd/jboss-as/tree/upgrades branch.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 10:00:23 2011
From: jira-events at lists.jboss.org (=?UTF-8?Q?Galder_Zamarre=C3=B1o_=28JIRA=29?=)
Date: Tue, 26 Jul 2011 10:00:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1141)
 LoadBalancePolicy that tries to pin all requests associated with a tx to
 one server
In-Reply-To: <31756017.1196688771620.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1033285423.82529.1311688823880.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/EJBTHREE-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Galder Zamarre?o reassigned EJBTHREE-1141:
------------------------------------------

    Assignee:     (was: Galder Zamarre?o)


> LoadBalancePolicy that tries to pin all requests associated with a tx to one server
> -----------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1141
>                 URL: https://issues.jboss.org/browse/EJBTHREE-1141
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Galder Zamarre?o
>
> Create EJB3 transaction sticky load balance policies.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Tue Jul 26 10:12:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 26 Jul 2011 10:12:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1404) Messaging Subsystem:
 Naming inconsitency
Message-ID: <1804074427.82591.1311689543720.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Messaging Subsystem: Naming inconsitency
----------------------------------------

                 Key: AS7-1404
                 URL: https://issues.jboss.org/browse/AS7-1404
             Project: Application Server 7
          Issue Type: Bug
          Components: Domain Management, JMS
    Affects Versions: 7.0.0.Final
            Reporter: Heiko Braun
            Assignee: Brian Stansberry
             Fix For: 7.0.1.Final


it seems the messaging subsystem prepends the "java:/" namespace to it JNDI names.
This is not the case for other subsystems and should be treated consistently:

I.e trying to add a queue 'java:/jboss/queues/myQueue' leads to:

{noformat}
16:07:54,288 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.naming.context.java.java:/jboss/queues/myQueue: org.jboss.msc.service.StartException in service jboss.naming.context.java.java:/jboss/queues/myQueue: Failed to bind resource into naming store [org.jboss.as.naming.InMemoryNamingStore at 4f3ad88b] at location [jboss/queues/myQueue]
	at org.jboss.as.naming.service.BinderService.start(BinderService.java:113)
	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_26]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]

{noformat} 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 10:12:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 26 Jul 2011 10:12:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1404) Messaging Subsystem:
 Naming inconsistency
In-Reply-To: <1804074427.82591.1311689543720.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2037130446.82595.1311689543831.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated AS7-1404:
-----------------------------

    Summary: Messaging Subsystem: Naming inconsistency  (was: Messaging Subsystem: Naming inconsitency)


> Messaging Subsystem: Naming inconsistency
> -----------------------------------------
>
>                 Key: AS7-1404
>                 URL: https://issues.jboss.org/browse/AS7-1404
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management, JMS
>    Affects Versions: 7.0.0.Final
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 7.0.1.Final
>
>
> it seems the messaging subsystem prepends the "java:/" namespace to it JNDI names.
> This is not the case for other subsystems and should be treated consistently:
> I.e trying to add a queue 'java:/jboss/queues/myQueue' leads to:
> {noformat}
> 16:07:54,288 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.naming.context.java.java:/jboss/queues/myQueue: org.jboss.msc.service.StartException in service jboss.naming.context.java.java:/jboss/queues/myQueue: Failed to bind resource into naming store [org.jboss.as.naming.InMemoryNamingStore at 4f3ad88b] at location [jboss/queues/myQueue]
> 	at org.jboss.as.naming.service.BinderService.start(BinderService.java:113)
> 	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_26]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
> 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> {noformat} 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 10:12:24 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 26 Jul 2011 10:12:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1402) domain-preview.xml
 bootstrap errors
In-Reply-To: <640583748.82260.1311684144331.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2098405486.82602.1311689544021.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616501#comment-12616501 ] 

Heiko Braun commented on AS7-1402:
----------------------------------

same happens with standalone-preview.xml

> domain-preview.xml bootstrap errors
> -----------------------------------
>
>                 Key: AS7-1402
>                 URL: https://issues.jboss.org/browse/AS7-1402
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Heiko Braun
>            Assignee: Clebert Suconic
>             Fix For: 7.0.1.Final
>
>
> The serves throws these errors when booting the preview.xml:
> {noformat}
> [Server:server-one] 14:37:20,714 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.messaging.jms.connection-factory.RemoteConnectionFactory: org.jboss.msc.service.StartException in service jboss.messaging.jms.connection-factory.RemoteConnectionFactory: failed to create connection-factory
> [Server:server-one] 	at org.jboss.as.messaging.jms.ConnectionFactoryService.start(ConnectionFactoryService.java:83)
> [Server:server-one] 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> [Server:server-one] 	at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> [Server:server-one] 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
> [Server:server-one] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
> [Server:server-one] 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> [Server:server-one] Caused by: HornetQException[errorCode=104 message=Connector 'netty' not found on the main configuration file]
> [Server:server-one] 	at org.hornetq.jms.server.impl.JMSServerManagerImpl.internalCreateCFPOJO(JMSServerManagerImpl.java:1174)
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 10:28:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 26 Jul 2011 10:28:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1405) Provide jms-topic DMR
	descriptions
Message-ID: <1943830937.82664.1311690503919.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Provide jms-topic DMR descriptions
----------------------------------

                 Key: AS7-1405
                 URL: https://issues.jboss.org/browse/AS7-1405
             Project: Application Server 7
          Issue Type: Bug
          Components: Domain Management, JMS
    Affects Versions: 7.0.0.Final
            Reporter: Heiko Braun
            Assignee: Brian Stansberry
             Fix For: 7.0.1.Final




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 10:42:24 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 26 Jul 2011 10:42:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1402) domain-preview.xml
 bootstrap errors
In-Reply-To: <640583748.82260.1311684144331.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2045226835.82722.1311691344393.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616514#comment-12616514 ] 

Heiko Braun commented on AS7-1402:
----------------------------------

steps to reproduce:

1) clean rebuild
2) boot "./bin/standalone.sh --server-config=standalone/configuration/standalone-preview.xml"
3) go into console, create a queue (myQueue, java:jboss/queues/myQueue)
4) shutdown server
5) reboot and watch sever log

> domain-preview.xml bootstrap errors
> -----------------------------------
>
>                 Key: AS7-1402
>                 URL: https://issues.jboss.org/browse/AS7-1402
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Heiko Braun
>            Assignee: Clebert Suconic
>             Fix For: 7.0.1.Final
>
>
> The serves throws these errors when booting the preview.xml:
> {noformat}
> [Server:server-one] 14:37:20,714 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.messaging.jms.connection-factory.RemoteConnectionFactory: org.jboss.msc.service.StartException in service jboss.messaging.jms.connection-factory.RemoteConnectionFactory: failed to create connection-factory
> [Server:server-one] 	at org.jboss.as.messaging.jms.ConnectionFactoryService.start(ConnectionFactoryService.java:83)
> [Server:server-one] 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> [Server:server-one] 	at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> [Server:server-one] 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
> [Server:server-one] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
> [Server:server-one] 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> [Server:server-one] Caused by: HornetQException[errorCode=104 message=Connector 'netty' not found on the main configuration file]
> [Server:server-one] 	at org.hornetq.jms.server.impl.JMSServerManagerImpl.internalCreateCFPOJO(JMSServerManagerImpl.java:1174)
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 10:42:25 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 26 Jul 2011 10:42:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1402) domain-preview.xml
 bootstrap errors
In-Reply-To: <640583748.82260.1311684144331.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1764371625.82737.1311691345457.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun reassigned AS7-1402:
--------------------------------

    Assignee: Emanuel Muckenhuber  (was: Clebert Suconic)


> domain-preview.xml bootstrap errors
> -----------------------------------
>
>                 Key: AS7-1402
>                 URL: https://issues.jboss.org/browse/AS7-1402
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Heiko Braun
>            Assignee: Emanuel Muckenhuber
>             Fix For: 7.0.1.Final
>
>
> The serves throws these errors when booting the preview.xml:
> {noformat}
> [Server:server-one] 14:37:20,714 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.messaging.jms.connection-factory.RemoteConnectionFactory: org.jboss.msc.service.StartException in service jboss.messaging.jms.connection-factory.RemoteConnectionFactory: failed to create connection-factory
> [Server:server-one] 	at org.jboss.as.messaging.jms.ConnectionFactoryService.start(ConnectionFactoryService.java:83)
> [Server:server-one] 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> [Server:server-one] 	at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> [Server:server-one] 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
> [Server:server-one] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
> [Server:server-one] 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> [Server:server-one] Caused by: HornetQException[errorCode=104 message=Connector 'netty' not found on the main configuration file]
> [Server:server-one] 	at org.hornetq.jms.server.impl.JMSServerManagerImpl.internalCreateCFPOJO(JMSServerManagerImpl.java:1174)
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 10:44:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 26 Jul 2011 10:44:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1402) JMS subsystem
	bootstrap errors
In-Reply-To: <640583748.82260.1311684144331.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <971460897.82741.1311691463648.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated AS7-1402:
-----------------------------

    Summary: JMS subsystem bootstrap errors  (was: domain-preview.xml bootstrap errors)


> JMS subsystem bootstrap errors
> ------------------------------
>
>                 Key: AS7-1402
>                 URL: https://issues.jboss.org/browse/AS7-1402
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Heiko Braun
>            Assignee: Emanuel Muckenhuber
>             Fix For: 7.0.1.Final
>
>
> The serves throws these errors when booting the preview.xml:
> {noformat}
> [Server:server-one] 14:37:20,714 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.messaging.jms.connection-factory.RemoteConnectionFactory: org.jboss.msc.service.StartException in service jboss.messaging.jms.connection-factory.RemoteConnectionFactory: failed to create connection-factory
> [Server:server-one] 	at org.jboss.as.messaging.jms.ConnectionFactoryService.start(ConnectionFactoryService.java:83)
> [Server:server-one] 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> [Server:server-one] 	at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> [Server:server-one] 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
> [Server:server-one] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
> [Server:server-one] 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> [Server:server-one] Caused by: HornetQException[errorCode=104 message=Connector 'netty' not found on the main configuration file]
> [Server:server-one] 	at org.hornetq.jms.server.impl.JMSServerManagerImpl.internalCreateCFPOJO(JMSServerManagerImpl.java:1174)
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 10:50:26 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 26 Jul 2011 10:50:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-1402) JMS
 subsystem bootstrap errors
In-Reply-To: <640583748.82260.1311684144331.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <871926709.82826.1311691826760.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616514#comment-12616514 ] 

Heiko Braun edited comment on AS7-1402 at 7/26/11 10:49 AM:
------------------------------------------------------------

steps to reproduce:

1) clean rebuild
2) boot "./bin/standalone.sh --server-config=standalone/configuration/standalone-preview.xml"
3) go into console, create a queue (myQueue, java:jboss/queues/myQueue)
4) shutdown server
5) reboot and watch server log

      was (Author: heiko.braun):
    steps to reproduce:

1) clean rebuild
2) boot "./bin/standalone.sh --server-config=standalone/configuration/standalone-preview.xml"
3) go into console, create a queue (myQueue, java:jboss/queues/myQueue)
4) shutdown server
5) reboot and watch sever log
  
> JMS subsystem bootstrap errors
> ------------------------------
>
>                 Key: AS7-1402
>                 URL: https://issues.jboss.org/browse/AS7-1402
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Heiko Braun
>            Assignee: Emanuel Muckenhuber
>             Fix For: 7.0.1.Final
>
>
> The serves throws these errors when booting the preview.xml:
> {noformat}
> [Server:server-one] 14:37:20,714 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.messaging.jms.connection-factory.RemoteConnectionFactory: org.jboss.msc.service.StartException in service jboss.messaging.jms.connection-factory.RemoteConnectionFactory: failed to create connection-factory
> [Server:server-one] 	at org.jboss.as.messaging.jms.ConnectionFactoryService.start(ConnectionFactoryService.java:83)
> [Server:server-one] 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> [Server:server-one] 	at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> [Server:server-one] 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
> [Server:server-one] 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
> [Server:server-one] 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> [Server:server-one] Caused by: HornetQException[errorCode=104 message=Connector 'netty' not found on the main configuration file]
> [Server:server-one] 	at org.hornetq.jms.server.impl.JMSServerManagerImpl.internalCreateCFPOJO(JMSServerManagerImpl.java:1174)
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 11:12:23 2011
From: jira-events at lists.jboss.org (Sebastian Jancke (JIRA))
Date: Tue, 26 Jul 2011 11:12:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1406) Classloading / module
 issue with using resteasy-jackson-provider and joda classes
Message-ID: <2129812508.82863.1311693143675.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Classloading / module issue with using resteasy-jackson-provider and joda classes
---------------------------------------------------------------------------------

                 Key: AS7-1406
                 URL: https://issues.jboss.org/browse/AS7-1406
             Project: Application Server 7
          Issue Type: Bug
          Components: Modules
    Affects Versions: 7.0.0.Final
            Reporter: Sebastian Jancke
            Assignee: David Lloyd


Classes of org.joda.time cannot be deserialized from JSON with the standard, built-in JodaDeserializer of org.codehaus.jackson, used by resteasy in the resteasy-jackson-provider.

Cause: jackson-mapper-asl (and possibly others) have no module-dependency to a (missing) module org.joda.time and thus cannot load the classes.

Stacktrace:
lang.ClassNotFoundException: org.joda.time.ReadableInstant from [Module "org.codehaus.jackson.jackson-mapper-asl:main" from local module loader @4ce66
f56 (roots: OBFUSCATED\jboss-as-7.0.0.Final\modules)]
        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
        at org.codehaus.jackson.map.ext.JodaDeserializers.provide(JodaDeserializers.java:32) [jackson-mapper-asl-1.6.3.jar:1.6.3]
        at org.codehaus.jackson.map.ext.OptionalHandlerFactory.findDeserializer(OptionalHandlerFactory.java:118) [jackson-mapper-asl-1.6.3.jar:1.6.3]
        at org.codehaus.jackson.map.deser.BasicDeserializerFactory.createBeanDeserializer(BasicDeserializerFactory.java:358) [jackson-mapper-asl-1.6.3.jar:1.6.3]
        at org.codehaus.jackson.map.deser.BeanDeserializerFactory.createBeanDeserializer(BeanDeserializerFactory.java:57) [jackson-mapper-asl-1.6.3.jar:1.6.3]
        at org.codehaus.jackson.map.deser.StdDeserializerProvider._createDeserializer(StdDeserializerProvider.java:342) [jackson-mapper-asl-1.6.3.jar:1.6.3]
        at org.codehaus.jackson.map.deser.StdDeserializerProvider._createAndCache2(StdDeserializerProvider.java:264) [jackson-mapper-asl-1.6.3.jar:1.6.3]
        at org.codehaus.jackson.map.deser.StdDeserializerProvider._createAndCacheValueDeserializer(StdDeserializerProvider.java:244) [jackson-mapper-asl-1.6.3.jar:1.6.3]
        at org.codehaus.jackson.map.deser.StdDeserializerProvider.findValueDeserializer(StdDeserializerProvider.java:111) [jackson-mapper-asl-1.6.3.jar:1.6.3]
        at org.codehaus.jackson.map.deser.StdDeserializer.findDeserializer(StdDeserializer.java:482) [jackson-mapper-asl-1.6.3.jar:1.6.3]
        at org.codehaus.jackson.map.deser.BeanDeserializer.resolve(BeanDeserializer.java:271) [jackson-mapper-asl-1.6.3.jar:1.6.3]
        at org.codehaus.jackson.map.deser.StdDeserializerProvider._resolveDeserializer(StdDeserializerProvider.java:348) [jackson-mapper-asl-1.6.3.jar:1.6.3]
        at org.codehaus.jackson.map.deser.StdDeserializerProvider._createAndCache2(StdDeserializerProvider.java:303) [jackson-mapper-asl-1.6.3.jar:1.6.3]
        at org.codehaus.jackson.map.deser.StdDeserializerProvider._createAndCacheValueDeserializer(StdDeserializerProvider.java:244) [jackson-mapper-asl-1.6.3.jar:1.6.3]
        at org.codehaus.jackson.map.deser.StdDeserializerProvider.findValueDeserializer(StdDeserializerProvider.java:111) [jackson-mapper-asl-1.6.3.jar:1.6.3]
        at org.codehaus.jackson.map.jsontype.impl.TypeDeserializerBase._findDeserializer(TypeDeserializerBase.java:77) [jackson-mapper-asl-1.6.3.jar:1.6.3]
        at org.codehaus.jackson.map.jsontype.impl.AsPropertyTypeDeserializer.deserializeTypedFromObject(AsPropertyTypeDeserializer.java:65) [jackson-mapper-asl-1.6.3.jar:1.6.3]
        at org.codehaus.jackson.map.deser.AbstractDeserializer.deserializeWithType(AbstractDeserializer.java:81) [jackson-mapper-asl-1.6.3.jar:1.6.3]
        at org.codehaus.jackson.map.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:147) [jackson-mapper-asl-1.6.3.jar:1.6.3]
        at org.codehaus.jackson.map.deser.SettableBeanProperty$MethodProperty.deserializeAndSet(SettableBeanProperty.java:237) [jackson-mapper-asl-1.6.3.jar:1.6.3]
        at org.codehaus.jackson.map.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:496) [jackson-mapper-asl-1.6.3.jar:1.6.3]
        at org.codehaus.jackson.map.deser.BeanDeserializer.deserialize(BeanDeserializer.java:350) [jackson-mapper-asl-1.6.3.jar:1.6.3]
        at org.codehaus.jackson.map.ObjectMapper._readValue(ObjectMapper.java:1961) [jackson-mapper-asl-1.6.3.jar:1.6.3]
        at org.codehaus.jackson.map.ObjectMapper.readValue(ObjectMapper.java:889) [jackson-mapper-asl-1.6.3.jar:1.6.3]
        at org.codehaus.jackson.jaxrs.JacksonJsonProvider.readFrom(JacksonJsonProvider.java:410)
        at org.jboss.resteasy.core.interception.MessageBodyReaderContextImpl.proceed(MessageBodyReaderContextImpl.java:105) [resteasy-jaxrs-2.2.1.GA.jar:]
        at org.jboss.resteasy.plugins.interceptors.encoding.GZIPDecodingInterceptor.read(GZIPDecodingInterceptor.java:61) [resteasy-jaxrs-2.2.1.GA.jar:]
        at org.jboss.resteasy.core.interception.MessageBodyReaderContextImpl.proceed(MessageBodyReaderContextImpl.java:108) [resteasy-jaxrs-2.2.1.GA.jar:]
        at org.jboss.resteasy.plugins.interceptors.encoding.GZIPDecodingInterceptor.read(GZIPDecodingInterceptor.java:61) [resteasy-jaxrs-2.2.1.GA.jar:]
        at org.jboss.resteasy.core.interception.MessageBodyReaderContextImpl.proceed(MessageBodyReaderContextImpl.java:108) [resteasy-jaxrs-2.2.1.GA.jar:]
        at org.jboss.resteasy.core.MessageBodyParameterInjector.inject(MessageBodyParameterInjector.java:168) [resteasy-jaxrs-2.2.1.GA.jar:]
        at org.jboss.resteasy.core.MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:114) [resteasy-jaxrs-2.2.1.GA.jar:]
        at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-2.2.1.GA.jar:]
        at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:255) [resteasy-jaxrs-2.2.1.GA.jar:]
        at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:220) [resteasy-jaxrs-2.2.1.GA.jar:]
        at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:209) [resteasy-jaxrs-2.2.1.GA.jar:]
        at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:519) [resteasy-jaxrs-2.2.1.GA.jar:]
        at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:496) [resteasy-jaxrs-2.2.1.GA.jar:]
        at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:119) [resteasy-jaxrs-2.2.1.GA.jar:]
        at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.2.1.GA.jar:]
        at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.2.1.GA.jar:]
        at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.2.1.GA.jar:]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67) [weld-core-1.1.2.AS7.jar:2011-07-06 12
:26]
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:480) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
        at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.0.0.Final.jar:7.0.0.Final]
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
        at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 11:30:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 26 Jul 2011 11:30:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1407) JNDI view operation
 doesn't show all entries
Message-ID: <1759022158.82897.1311694223635.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

JNDI view operation doesn't show all entries
--------------------------------------------

                 Key: AS7-1407
                 URL: https://issues.jboss.org/browse/AS7-1407
             Project: Application Server 7
          Issue Type: Enhancement
          Components: Domain Management
            Reporter: Heiko Braun
            Assignee: Brian Stansberry


don't ask me why, but a queue (java:/jboss/queues/myQueue) for instance is not shown. Same thing for resource adapter, etc.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 11:32:23 2011
From: jira-events at lists.jboss.org (Sebastian Jancke (JIRA))
Date: Tue, 26 Jul 2011 11:32:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1406) Classloading /
 module issue with using resteasy-jackson-provider and joda classes
In-Reply-To: <2129812508.82863.1311693143675.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2005090180.82904.1311694343803.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616519#comment-12616519 ] 

Sebastian Jancke commented on AS7-1406:
---------------------------------------

Fix:
[module.xml of org.codehaus.jackson.jackson-mapper-asl]
<module xmlns="urn:jboss:module:1.0" name="org.codehaus.jackson.jackson-mapper-asl">
  <resources>
    <resource-root path="jackson-mapper-asl-1.6.3.jar"/>
        <!-- Insert resources here -->
  </resources>

  <dependencies>
      <module name="org.codehaus.jackson.jackson-core-asl"/>
      <module name="javax.api" />
      <module name="org.joda.time" />
  </dependencies>
</module>

[new module org.joda.time]
<module xmlns="urn:jboss:module:1.0" name="org.joda.time">
  <resources>
    <resource-root path="joda-time-1.6.2.jar"/>
        <!-- Insert resources here -->
  </resources>

  <dependencies>      
  </dependencies>
</module>

> Classloading / module issue with using resteasy-jackson-provider and joda classes
> ---------------------------------------------------------------------------------
>
>                 Key: AS7-1406
>                 URL: https://issues.jboss.org/browse/AS7-1406
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Modules
>    Affects Versions: 7.0.0.Final
>            Reporter: Sebastian Jancke
>            Assignee: David Lloyd
>              Labels: classloader, jodatime, resteasy
>
> Classes of org.joda.time cannot be deserialized from JSON with the standard, built-in JodaDeserializer of org.codehaus.jackson, used by resteasy in the resteasy-jackson-provider.
> Cause: jackson-mapper-asl (and possibly others) have no module-dependency to a (missing) module org.joda.time and thus cannot load the classes.
> Stacktrace:
> lang.ClassNotFoundException: org.joda.time.ReadableInstant from [Module "org.codehaus.jackson.jackson-mapper-asl:main" from local module loader @4ce66
> f56 (roots: OBFUSCATED\jboss-as-7.0.0.Final\modules)]
>         at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
>         at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
>         at org.codehaus.jackson.map.ext.JodaDeserializers.provide(JodaDeserializers.java:32) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.ext.OptionalHandlerFactory.findDeserializer(OptionalHandlerFactory.java:118) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.BasicDeserializerFactory.createBeanDeserializer(BasicDeserializerFactory.java:358) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.BeanDeserializerFactory.createBeanDeserializer(BeanDeserializerFactory.java:57) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.StdDeserializerProvider._createDeserializer(StdDeserializerProvider.java:342) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.StdDeserializerProvider._createAndCache2(StdDeserializerProvider.java:264) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.StdDeserializerProvider._createAndCacheValueDeserializer(StdDeserializerProvider.java:244) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.StdDeserializerProvider.findValueDeserializer(StdDeserializerProvider.java:111) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.StdDeserializer.findDeserializer(StdDeserializer.java:482) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.BeanDeserializer.resolve(BeanDeserializer.java:271) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.StdDeserializerProvider._resolveDeserializer(StdDeserializerProvider.java:348) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.StdDeserializerProvider._createAndCache2(StdDeserializerProvider.java:303) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.StdDeserializerProvider._createAndCacheValueDeserializer(StdDeserializerProvider.java:244) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.StdDeserializerProvider.findValueDeserializer(StdDeserializerProvider.java:111) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.jsontype.impl.TypeDeserializerBase._findDeserializer(TypeDeserializerBase.java:77) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.jsontype.impl.AsPropertyTypeDeserializer.deserializeTypedFromObject(AsPropertyTypeDeserializer.java:65) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.AbstractDeserializer.deserializeWithType(AbstractDeserializer.java:81) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:147) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.SettableBeanProperty$MethodProperty.deserializeAndSet(SettableBeanProperty.java:237) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:496) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.BeanDeserializer.deserialize(BeanDeserializer.java:350) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.ObjectMapper._readValue(ObjectMapper.java:1961) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.ObjectMapper.readValue(ObjectMapper.java:889) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.jaxrs.JacksonJsonProvider.readFrom(JacksonJsonProvider.java:410)
>         at org.jboss.resteasy.core.interception.MessageBodyReaderContextImpl.proceed(MessageBodyReaderContextImpl.java:105) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.plugins.interceptors.encoding.GZIPDecodingInterceptor.read(GZIPDecodingInterceptor.java:61) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.core.interception.MessageBodyReaderContextImpl.proceed(MessageBodyReaderContextImpl.java:108) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.plugins.interceptors.encoding.GZIPDecodingInterceptor.read(GZIPDecodingInterceptor.java:61) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.core.interception.MessageBodyReaderContextImpl.proceed(MessageBodyReaderContextImpl.java:108) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.core.MessageBodyParameterInjector.inject(MessageBodyParameterInjector.java:168) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.core.MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:114) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:255) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:220) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:209) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:519) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:496) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:119) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67) [weld-core-1.1.2.AS7.jar:2011-07-06 12
> :26]
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:480) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.0.0.Final.jar:7.0.0.Final]
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 11:35:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 26 Jul 2011 11:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1407) JNDI view operation
 doesn't show all entries
In-Reply-To: <1759022158.82897.1311694223635.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <64075756.82907.1311694523699.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616520#comment-12616520 ] 

Heiko Braun commented on AS7-1407:
----------------------------------

Here's an example:

{noformat}

[standalone at localhost:9999 /] /subsystem=resource-adapters/resource-adapter=xmpp-ra.rar:read-attribute(name=connection-definitions)
{
    "outcome" => "success",
    "result" => [{
        "class-name" => "com.ramphastos.xmpp.XmppConnectionFactory",
        "jndi-name" => "java:jboss/eis/xmpp",
        "pool-name" => "xmpp-ra_rar-Pool"
    }]
}

{noformat}


{noformat}
[standalone at localhost:9999 /] /subsystem=naming:jndi-view
{
    "outcome" => "success",
    "result" => {
        "java: contexts" => {
            "java:jboss" => {
                "jaas" => {
                    "class-name" => "org.jboss.as.naming.context.ModularReference",
                    "children" => {"other" => {
                        "class-name" => "org.jboss.as.security.plugins.SecurityDomainContext",
                        "value" => "org.jboss.security.authentication.JBossCachedAuthenticationManager at 2c9fac35"
                    }}
                },
                "TransactionManager" => {
                    "class-name" => "org.jboss.as.naming.context.ModularReference",
                    "value" => "com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate at 36a75e9f"
                },
                "datasources" => {
                    "class-name" => "javax.naming.Context",
                    "children" => {"ExampleDS" => {
                        "class-name" => "org.jboss.as.naming.context.ModularReference",
                        "value" => "org.jboss.jca.adapters.jdbc.WrapperDataSource at 6f1a7e7f"
                    }}
                },
                "TransactionSynchronizationRegistry" => {
                    "class-name" => "org.jboss.as.naming.context.ModularReference",
                    "value" => "com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionSynchronizationRegistryImple at 55611ed3"
                },
                "mysql" => {
                    "class-name" => "org.jboss.as.naming.context.ModularReference",
                    "value" => "org.jboss.jca.adapters.jdbc.WrapperDataSource at 5eba06ff"
                }
            },
            "java:global" => undefined
        },
        "applications" => {
            "mysql-connector-java-5.1.15.jar" => {
                "java:app" => {"AppName" => {
                    "class-name" => "org.jboss.as.naming.context.ModularReference",
                    "value" => "mysql-connector-java-5.1.15"
                }},
                "modules" => {"mysql-connector-java-5.1.15" => {"java:module" => {"ModuleName" => {
                    "class-name" => "org.jboss.as.naming.context.ModularReference",
                    "value" => "mysql-connector-java-5.1.15"
                }}}}
            },
            "xmpp-ra.rar" => {
                "java:app" => {"AppName" => {
                    "class-name" => "org.jboss.as.naming.context.ModularReference",
                    "value" => "xmpp-ra"
                }},
                "modules" => {"xmpp-ra" => {"java:module" => {"ModuleName" => {
                    "class-name" => "org.jboss.as.naming.context.ModularReference",
                    "value" => "xmpp-ra"
                }}}}
            }
        }
    }
}

{noformat}

> JNDI view operation doesn't show all entries
> --------------------------------------------
>
>                 Key: AS7-1407
>                 URL: https://issues.jboss.org/browse/AS7-1407
>             Project: Application Server 7
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>
> don't ask me why, but a queue (java:/jboss/queues/myQueue) for instance is not shown. Same thing for resource adapter, etc.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 11:37:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 26 Jul 2011 11:37:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1407) JNDI view operation
 doesn't show all entries
In-Reply-To: <1759022158.82897.1311694223635.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1276944813.82914.1311694643956.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616521#comment-12616521 ] 

Heiko Braun commented on AS7-1407:
----------------------------------

Maybe some of these element are bound lazily?

> JNDI view operation doesn't show all entries
> --------------------------------------------
>
>                 Key: AS7-1407
>                 URL: https://issues.jboss.org/browse/AS7-1407
>             Project: Application Server 7
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>
> don't ask me why, but a queue (java:/jboss/queues/myQueue) for instance is not shown. Same thing for resource adapter, etc.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 11:47:23 2011
From: jira-events at lists.jboss.org (Sebastian Jancke (JIRA))
Date: Tue, 26 Jul 2011 11:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1408) Missing
 module-dependency breacks reconfiguring jackson ObjectMapper with using
 resteasy-jackson-provider
Message-ID: <410650910.82917.1311695243605.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Missing module-dependency breacks reconfiguring jackson ObjectMapper with using resteasy-jackson-provider
---------------------------------------------------------------------------------------------------------

                 Key: AS7-1408
                 URL: https://issues.jboss.org/browse/AS7-1408
             Project: Application Server 7
          Issue Type: Bug
          Components: Modules
    Affects Versions: 7.0.0.Final
            Reporter: Sebastian Jancke
            Assignee: David Lloyd


When using resteasy with resteasy-jackson-provider, classloading from jackson-xc to jackson-core-asl is not working because the module-dependency is missing.

Stacktrace:
17:12:24,479 WARN  [org.jboss.modules] (MSC service thread 1-8) Failed to define class org.codehaus.jackson.xc.JaxbAnnotationIntrospector in Module "org.codehaus.jackson.jackson-xc:main" from local module loader @4ce66f56 (roots: OBFUSCATED\jboss-as-7.0.0.Final\modules): java.lang.LinkageError: Failed
 to link org/codehaus/jackson/xc/JaxbAnnotationIntrospector (Module "org.codehaus.jackson.jackson-xc:main" from local module loader @4ce66f56 (roots:
 OBFUSCATED\jboss-as-7.0.0.Final\modules))
        at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:401)
        at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261)
        at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76)
        at org.jboss.modules.Module.loadModuleClass(Module.java:588)
        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:183)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
        at java.lang.Class.getDeclaredFields0(Native Method) [:1.6.0_24]
        at java.lang.Class.privateGetDeclaredFields(Class.java:2291) [:1.6.0_24]
        at java.lang.Class.getDeclaredFields(Class.java:1743) [:1.6.0_24]
        at org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:116) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
        at org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:112) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
        at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
        at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:67) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
        at org.jboss.weld.util.reflection.SecureReflections.getDeclaredFields(SecureReflections.java:111) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
        at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:163) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
        at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:124) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
        at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:54) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
        at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:42) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
        at com.google.common.collect.ComputingConcurrentHashMap.compute(ComputingConcurrentHashMap.java:206) [guava-r07.jar:]
        at com.google.common.collect.ComputingConcurrentHashMap.apply(ComputingConcurrentHashMap.java:100) [guava-r07.jar:]
        at com.google.common.collect.MapMaker$ComputingMapAdapter.get(MapMaker.java:515) [guava-r07.jar:]
        at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:183) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
        at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:96) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
        at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:133) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
        at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:191) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
        at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:368) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
        at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:81) [jboss-as-weld-7.0.0.Final.jar:7.0.0.Final]
        at org.jboss.as.weld.services.WeldService.start(WeldService.java:89) [jboss-as-weld-7.0.0.Final.jar:7.0.0.Final]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
        at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
        at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
Caused by: java.lang.NoClassDefFoundError: org/codehaus/jackson/Versioned
        at java.lang.ClassLoader.defineClass1(Native Method) [:1.6.0_24]
        at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) [:1.6.0_24]
        at java.lang.ClassLoader.defineClass(ClassLoader.java:616) [:1.6.0_24]
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) [:1.6.0_24]
        at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:397)
        ... 35 more
Caused by: java.lang.ClassNotFoundException: org.codehaus.jackson.Versioned from [Module "org.codehaus.jackson.jackson-xc:main" from local module loader @4ce66f56 (roots: OBFUSCATED\jboss-as-7.0.0.Final\modules)]
        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
        ... 40 more



FIX [module org.codehaus.jackson.jackson-xc]
<module xmlns="urn:jboss:module:1.0" name="org.codehaus.jackson.jackson-xc">
  <resources>
    <resource-root path="jackson-xc-1.6.3.jar"/>
        <!-- Insert resources here -->
  </resources>

  <dependencies>
      <module name="javax.api" />
      <module name="javax.activation.api" />
      <module name="javax.xml.bind.api" />
      <module name="org.codehaus.jackson.jackson-mapper-asl" />
      <module name="org.codehaus.jackson.jackson-core-asl" />
  </dependencies>
</module>

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 13:24:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 26 Jul 2011 13:24:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-637) DataSource support
Message-ID: <1011027992.83055.1311701063649.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

DataSource support
------------------

                 Key: JBJCA-637
                 URL: https://issues.jboss.org/browse/JBJCA-637
             Project: IronJacamar
          Issue Type: Task
          Components: Common, Deployer, JDBC
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.2.Final, 1.1.0.Alpha1


We should support <datasource> deployments based on a javax.sql.DataSource instance.

Add <datasource-class> to <datasource> and <driver> as optional.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 15:06:23 2011
From: jira-events at lists.jboss.org (Justin Bertram (JIRA))
Date: Tue, 26 Jul 2011 15:06:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBJCA-637) DataSource support
In-Reply-To: <1011027992.83055.1311701063649.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2032756805.83241.1311707183703.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616563#comment-12616563 ] 

Justin Bertram commented on JBJCA-637:
--------------------------------------

Will this automatically disable "our" pooling so that pooling can be delegating to the underlying <datasource-class>?  If not, we might want to add another option for this because some vendors' javax.sql.DataSource implementations do their own pooling.

> DataSource support
> ------------------
>
>                 Key: JBJCA-637
>                 URL: https://issues.jboss.org/browse/JBJCA-637
>             Project: IronJacamar
>          Issue Type: Task
>          Components: Common, Deployer, JDBC
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.2.Final, 1.1.0.Alpha1
>
>
> We should support <datasource> deployments based on a javax.sql.DataSource instance.
> Add <datasource-class> to <datasource> and <driver> as optional.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 15:10:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 26 Jul 2011 15:10:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBJCA-637) DataSource support
In-Reply-To: <1011027992.83055.1311701063649.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <620677666.83257.1311707423673.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616566#comment-12616566 ] 

Jesper Pedersen commented on JBJCA-637:
---------------------------------------

No, it doesn't atm. And I don't see the use-case for that, since all databases I know of provides a "clean" javax.sql.DataSource implementation. Use the forum in the future for discussions.

> DataSource support
> ------------------
>
>                 Key: JBJCA-637
>                 URL: https://issues.jboss.org/browse/JBJCA-637
>             Project: IronJacamar
>          Issue Type: Task
>          Components: Common, Deployer, JDBC
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.2.Final, 1.1.0.Alpha1
>
>
> We should support <datasource> deployments based on a javax.sql.DataSource instance.
> Add <datasource-class> to <datasource> and <driver> as optional.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 15:13:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 26 Jul 2011 15:13:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1365) Add configurable
 jvm-route to web subsystem to support mod_jk and mod_proxy.
In-Reply-To: <879296760.73495.1311277163672.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <723367033.83262.1311707603754.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616567#comment-12616567 ] 

Paul Ferraro commented on AS7-1365:
-----------------------------------

Remy,
Are you talking about the automagic logic in the mod_cluster subsystem?
There are a couple issues with this:
* The autogenerated jvm-routes are UUIDs.  While the generated values are indeed consistent (i.e. not random), they aren't really known until the server starts.  Since mod_jk/mod_proxy needs to define these explicitly (e.g. in workers.properties), this becomes a little awkward to setup.
* mod_jk/mod_proxy users may not realize that they need the mod_cluster subsystem for jvm-route autogeneration (it's not obvious).  This is more of a documentation issue, really.

> Add configurable jvm-route to web subsystem to support mod_jk and mod_proxy.
> ----------------------------------------------------------------------------
>
>                 Key: AS7-1365
>                 URL: https://issues.jboss.org/browse/AS7-1365
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Web
>    Affects Versions: 7.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Remy Maucherat
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 15:15:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 26 Jul 2011 15:15:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1364) Upgrade Infinispan
	to 5.0.0.CR8
In-Reply-To: <1578003038.73331.1311270923689.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <138084392.83268.1311707723759.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro resolved AS7-1364.
-------------------------------

    Resolution: Done


> Upgrade Infinispan to 5.0.0.CR8
> -------------------------------
>
>                 Key: AS7-1364
>                 URL: https://issues.jboss.org/browse/AS7-1364
>             Project: Application Server 7
>          Issue Type: Component  Upgrade
>          Components: Clustering
>    Affects Versions: 7.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 7.0.1.Final, 7.1.0.Alpha1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 15:17:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Tue, 26 Jul 2011 15:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1313) <distributable> web
 applications fail to deploy with the default configuration
In-Reply-To: <540578067.59906.1310987543621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1039687807.83273.1311707843796.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro reassigned AS7-1313:
---------------------------------

    Assignee: Paul Ferraro  (was: Remy Maucherat)


> <distributable> web applications fail to deploy with the default configuration
> ------------------------------------------------------------------------------
>
>                 Key: AS7-1313
>                 URL: https://issues.jboss.org/browse/AS7-1313
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>            Reporter: Stuart Douglas
>            Assignee: Paul Ferraro
>
> <distributable> web applications fail with the following:
> "Services with missing/unavailable dependencies" => ["jboss.web.\"magnolia-bundled-webapp-4.4.4.war\" missing [ jboss.infinispan.web.___defaultcache ]"]}}}
> At the very least the user should get a better error message explaining why their deployment failed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 17:30:23 2011
From: jira-events at lists.jboss.org (Misty Stanley-Jones (JIRA))
Date: Tue, 26 Jul 2011 17:30:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1365) Add configurable
 jvm-route to web subsystem to support mod_jk and mod_proxy.
In-Reply-To: <879296760.73495.1311277163672.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1690619592.83408.1311715823714.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616577#comment-12616577 ] 

Misty Stanley-Jones commented on AS7-1365:
------------------------------------------

Paul, if it is a docs issue, can you lay it out so that we can capture it in the documentation? I'm not sure who is working on the community docs, but I would be happy to share with them. Basically, what exactly needs to happen for mod_cluster/mod_jk to work, from an admin's POV? Step-by-step would be best.

> Add configurable jvm-route to web subsystem to support mod_jk and mod_proxy.
> ----------------------------------------------------------------------------
>
>                 Key: AS7-1365
>                 URL: https://issues.jboss.org/browse/AS7-1365
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Web
>    Affects Versions: 7.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Remy Maucherat
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 19:14:24 2011
From: jira-events at lists.jboss.org (Dennis Reed (JIRA))
Date: Tue, 26 Jul 2011 19:14:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-2110) Add flag to
 enable an optimization to skip serialization/deserialization of Remote
 interfaces running locally
In-Reply-To: <334283201.6354.1276096358289.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <407765470.83552.1311722064422.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/EJBTHREE-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616594#comment-12616594 ] 

Dennis Reed commented on EJBTHREE-2110:
---------------------------------------

There's a typo in the property name in Carlo's comment.
It should be "org.jboss.ejb3.remoting.IsLocalInterceptor.passByRef"

> Add flag to enable an optimization to skip serialization/deserialization of Remote interfaces running locally
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-2110
>                 URL: https://issues.jboss.org/browse/EJBTHREE-2110
>             Project: EJB 3.0
>          Issue Type: Feature Request
>            Reporter: Ben Schofield
>            Assignee: Carlo de Wolf
>             Fix For: bom-eap5-0.1.3, depchain-1.0.0-alpha-2
>
>         Attachments: EJBTHREE-2110.patch
>
>
> When an application uses a remote EJB3 interface the call is serialized and deserialized.  While mandated by spec this is unnecessary if the EJB is running in the same JVM as the calling client.  Having the option to skip serialization would bring JBoss inline with other major JEE vendors.  Performance tests on a transactional application that has all business logic in stateless session bean methods is showing 20% cpu overhead just for the serialization.  Having 20% more production CPU capacity is more important than claiming strict EJB3 compliance.  JBoss AS response times are better too.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 19:56:23 2011
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 26 Jul 2011 19:56:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1177) Implement JavaMail
In-Reply-To: <371450412.33446.1309771103714.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1444557066.83591.1311724583796.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616599#comment-12616599 ] 

Tomaz Cerar commented on AS7-1177:
----------------------------------

Current config looks like this:

{code:xml}
 <mail-session jndi-name="java:/Mail" debug="true">
                <login name="nobody" password="pass"/>
                <smtp-server address="localhost" port="9999"/>
           </mail-session>
            <mail-session jndi-name="foo/MyMailServer1">
                <login name="user" password="pass"/>
                <smtp-server address="remote" port="25"/>
           </mail-session>
{code}

I am not using port binding as we are actually not binding to any server ports (as jboss ports) but just use address and port.

aditional java mail properties are supported as attributes on mail-session as George suggested, currently only "debug" is read and used.
Code in my github branch now uses this configuration and creates metamodel and registers the services in jndi. 
David, as you suggested if jndi name does not start with "java:" it is put under  "java:jboss/mail/" + rawJndiName

The creation of mail session itself is not finished yet but should be trivial after I get some sleep :)

next thing as for configuration goes I will add similar support of pop3 server with config something like:
{code:xml}
<pop3-server address="remote.address" port="125" />
{code}

George, It would be great help if you could provide some integration tests for this. I have some tests but not nearly enough :)

> Implement JavaMail
> ------------------
>
>                 Key: AS7-1177
>                 URL: https://issues.jboss.org/browse/AS7-1177
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Modules
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: Tomaz Cerar
>
> JavaMail cannot be used as it was in JBossAS 6 and earlier.
> 1) I tried as in JBoss 6:
> @Resource(mappedName = "java:Mail")
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:12:08,454 INFO  [org.jboss.as.server.controller] (pool-1-thread-48) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.naming.context.java.comp.\"test.ear\".test.KundenverwaltungListener.\"env/de.swe2.kundenverwaltung.service.KundenverwaltungListener/mailer\".jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.8","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Dao.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.ValidationService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Kundenverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Artikelverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.FileStore.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.RolesService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.BestellverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.PasswordService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".jndiDependencyService","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Bestellverwaltung.START"]}
> 11:12:08,468 INFO  [org.jboss.jpa] (MSC service thread 1-1) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:12:08,470 INFO  [org.jboss.weld] (MSC service thread 1-1) Stopping weld service
> 2) I tried
> @Resource
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:09:20,085 INFO  [org.jboss.as.server.controller] (pool-1-thread-46) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START"]}
> 11:09:20,094 INFO  [org.jboss.jpa] (MSC service thread 1-2) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:09:20,098 INFO  [org.jboss.weld] (MSC service thread 1-2) Stopping weld service

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Tue Jul 26 20:52:23 2011
From: jira-events at lists.jboss.org (Rohit Chourasia (JIRA))
Date: Tue, 26 Jul 2011 20:52:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1284) Accessing
 localhost:8080 using JBoss Web Native causes
 java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
In-Reply-To: <2087989740.53707.1310651303687.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1880993947.83659.1311727943671.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616606#comment-12616606 ] 

Rohit Chourasia commented on AS7-1284:
--------------------------------------

I have tried David Lloyd's fix, however that does not solve the problem.

> Accessing localhost:8080 using JBoss Web Native causes java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1284
>                 URL: https://issues.jboss.org/browse/AS7-1284
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>         Environment: Darwin osx-en-jwegne.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) Client VM (build 20.1-b02-384, mixed mode)
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)
>            Reporter: Josef Wegner
>            Assignee: Remy Maucherat
>            Priority: Minor
>         Attachments: libtcnative-1.jnilib
>
>
> Hi,
> accessing http://localhost:8080 using JBoss Web Native 2.0.9 (self compiled for x64 and downloaded from http://www.jboss.org/jbossweb/downloads/jboss-native-2-0-9.html for i386) causes following stack trace:
> {quote}
> 15:23:18,710 ERROR [org.apache.coyote.http11.Http11AprProtocol] (http--127.0.0.1-8080-1) Error reading request, ignored: java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> 	at org.apache.tomcat.jni.Socket.setrbb(Native Method)
> 	at org.apache.coyote.http11.InternalAprInputBuffer.setSocket(InternalAprInputBuffer.java:202)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:825)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: java.lang.ClassNotFoundException: sun.nio.ch.DirectBuffer from [Module "org.jboss.as.web:main" from local module loader @39e87719 (roots: /Users/jwegne/Tools/jboss-as-web-7.0.0.Final/modules)]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
> 	... 6 more
> {quote}
> This happens with only when using JDK 1.6 provided by Apple. OpenJDK 1.7 (self-compiled) works, though.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 21:03:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 26 Jul 2011 21:03:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1284) Accessing
 localhost:8080 using JBoss Web Native causes
 java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
In-Reply-To: <2087989740.53707.1310651303687.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <297273334.83698.1311728603664.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616607#comment-12616607 ] 

David Lloyd commented on AS7-1284:
----------------------------------

Ah, I see I only included sun.nio, not sun.nio.ch.  Try this patch instead:

https://github.com/dmlloyd/jboss-as/commit/aa1ad71

> Accessing localhost:8080 using JBoss Web Native causes java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1284
>                 URL: https://issues.jboss.org/browse/AS7-1284
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>         Environment: Darwin osx-en-jwegne.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) Client VM (build 20.1-b02-384, mixed mode)
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)
>            Reporter: Josef Wegner
>            Assignee: Remy Maucherat
>            Priority: Minor
>         Attachments: libtcnative-1.jnilib
>
>
> Hi,
> accessing http://localhost:8080 using JBoss Web Native 2.0.9 (self compiled for x64 and downloaded from http://www.jboss.org/jbossweb/downloads/jboss-native-2-0-9.html for i386) causes following stack trace:
> {quote}
> 15:23:18,710 ERROR [org.apache.coyote.http11.Http11AprProtocol] (http--127.0.0.1-8080-1) Error reading request, ignored: java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> 	at org.apache.tomcat.jni.Socket.setrbb(Native Method)
> 	at org.apache.coyote.http11.InternalAprInputBuffer.setSocket(InternalAprInputBuffer.java:202)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:825)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: java.lang.ClassNotFoundException: sun.nio.ch.DirectBuffer from [Module "org.jboss.as.web:main" from local module loader @39e87719 (roots: /Users/jwegne/Tools/jboss-as-web-7.0.0.Final/modules)]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
> 	... 6 more
> {quote}
> This happens with only when using JDK 1.6 provided by Apple. OpenJDK 1.7 (self-compiled) works, though.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 21:26:24 2011
From: jira-events at lists.jboss.org (Rohit Chourasia (JIRA))
Date: Tue, 26 Jul 2011 21:26:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1284) Accessing
 localhost:8080 using JBoss Web Native causes
 java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
In-Reply-To: <2087989740.53707.1310651303687.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1720383775.83710.1311729984081.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616608#comment-12616608 ] 

Rohit Chourasia commented on AS7-1284:
--------------------------------------

Thanks David. It works now with sun.nio.ch

> Accessing localhost:8080 using JBoss Web Native causes java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1284
>                 URL: https://issues.jboss.org/browse/AS7-1284
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>         Environment: Darwin osx-en-jwegne.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) Client VM (build 20.1-b02-384, mixed mode)
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)
>            Reporter: Josef Wegner
>            Assignee: Remy Maucherat
>            Priority: Minor
>         Attachments: libtcnative-1.jnilib
>
>
> Hi,
> accessing http://localhost:8080 using JBoss Web Native 2.0.9 (self compiled for x64 and downloaded from http://www.jboss.org/jbossweb/downloads/jboss-native-2-0-9.html for i386) causes following stack trace:
> {quote}
> 15:23:18,710 ERROR [org.apache.coyote.http11.Http11AprProtocol] (http--127.0.0.1-8080-1) Error reading request, ignored: java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> 	at org.apache.tomcat.jni.Socket.setrbb(Native Method)
> 	at org.apache.coyote.http11.InternalAprInputBuffer.setSocket(InternalAprInputBuffer.java:202)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:825)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: java.lang.ClassNotFoundException: sun.nio.ch.DirectBuffer from [Module "org.jboss.as.web:main" from local module loader @39e87719 (roots: /Users/jwegne/Tools/jboss-as-web-7.0.0.Final/modules)]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
> 	... 6 more
> {quote}
> This happens with only when using JDK 1.6 provided by Apple. OpenJDK 1.7 (self-compiled) works, though.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 22:07:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 26 Jul 2011 22:07:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1284) Accessing
 localhost:8080 using JBoss Web Native causes
 java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
In-Reply-To: <2087989740.53707.1310651303687.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <22411270.83723.1311732443670.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616610#comment-12616610 ] 

David Lloyd commented on AS7-1284:
----------------------------------

Excellent, I'll get it upstream.


> Accessing localhost:8080 using JBoss Web Native causes java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1284
>                 URL: https://issues.jboss.org/browse/AS7-1284
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>         Environment: Darwin osx-en-jwegne.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) Client VM (build 20.1-b02-384, mixed mode)
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)
>            Reporter: Josef Wegner
>            Assignee: Remy Maucherat
>            Priority: Minor
>         Attachments: libtcnative-1.jnilib
>
>
> Hi,
> accessing http://localhost:8080 using JBoss Web Native 2.0.9 (self compiled for x64 and downloaded from http://www.jboss.org/jbossweb/downloads/jboss-native-2-0-9.html for i386) causes following stack trace:
> {quote}
> 15:23:18,710 ERROR [org.apache.coyote.http11.Http11AprProtocol] (http--127.0.0.1-8080-1) Error reading request, ignored: java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> 	at org.apache.tomcat.jni.Socket.setrbb(Native Method)
> 	at org.apache.coyote.http11.InternalAprInputBuffer.setSocket(InternalAprInputBuffer.java:202)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:825)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: java.lang.ClassNotFoundException: sun.nio.ch.DirectBuffer from [Module "org.jboss.as.web:main" from local module loader @39e87719 (roots: /Users/jwegne/Tools/jboss-as-web-7.0.0.Final/modules)]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
> 	... 6 more
> {quote}
> This happens with only when using JDK 1.6 provided by Apple. OpenJDK 1.7 (self-compiled) works, though.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 22:09:24 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 26 Jul 2011 22:09:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1284) Accessing
 localhost:8080 using JBoss Web Native causes
 java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
In-Reply-To: <2087989740.53707.1310651303687.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <785635124.83735.1311732564464.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved AS7-1284.
------------------------------

    Fix Version/s: 7.0.1.Final
       Resolution: Done


> Accessing localhost:8080 using JBoss Web Native causes java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1284
>                 URL: https://issues.jboss.org/browse/AS7-1284
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>         Environment: Darwin osx-en-jwegne.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) Client VM (build 20.1-b02-384, mixed mode)
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425)
> Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode)
>            Reporter: Josef Wegner
>            Assignee: Remy Maucherat
>            Priority: Minor
>             Fix For: 7.0.1.Final
>
>         Attachments: libtcnative-1.jnilib
>
>
> Hi,
> accessing http://localhost:8080 using JBoss Web Native 2.0.9 (self compiled for x64 and downloaded from http://www.jboss.org/jbossweb/downloads/jboss-native-2-0-9.html for i386) causes following stack trace:
> {quote}
> 15:23:18,710 ERROR [org.apache.coyote.http11.Http11AprProtocol] (http--127.0.0.1-8080-1) Error reading request, ignored: java.lang.NoClassDefFoundError: sun/nio/ch/DirectBuffer
> 	at org.apache.tomcat.jni.Socket.setrbb(Native Method)
> 	at org.apache.coyote.http11.InternalAprInputBuffer.setSocket(InternalAprInputBuffer.java:202)
> 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:825)
> 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626)
> 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2054)
> 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> Caused by: java.lang.ClassNotFoundException: sun.nio.ch.DirectBuffer from [Module "org.jboss.as.web:main" from local module loader @39e87719 (roots: /Users/jwegne/Tools/jboss-as-web-7.0.0.Final/modules)]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
> 	... 6 more
> {quote}
> This happens with only when using JDK 1.6 provided by Apple. OpenJDK 1.7 (self-compiled) works, though.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 23:11:23 2011
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 26 Jul 2011 23:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1403) Excluded/Banned
 transitive dependencies for Maven Dependency Resolver are too strict
In-Reply-To: <415854736.82382.1311685883624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1989939524.83763.1311736283637.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616614#comment-12616614 ] 

Paul Gier commented on AS7-1403:
--------------------------------

I'm not sure I understand the problem.  The transitive dependencies in many cases were already flattened instead of removed.  The ones that were removed were not needed.  If the testsuite requires certain dependencies, can't they be added directly to the testsuite poms?

> Excluded/Banned transitive dependencies for Maven Dependency Resolver are too strict
> ------------------------------------------------------------------------------------
>
>                 Key: AS7-1403
>                 URL: https://issues.jboss.org/browse/AS7-1403
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Build System
>    Affects Versions: 7.0.0.Final
>            Reporter: Karel Piwko
>            Assignee: Paul Gier
>
> During 7.0.0.CR1 build, there was a decision to remove transitive dependencies from other projects and exclude/ban them in jboss-as-parent.
> This decision has effectively crippled usage of Maven Dependency Resolver, which wasn't used in CR1-date based testsuite, so the change passed silently. 
> If user wants to use the ShrinkWrap Dependency Resolver in the AS7 testsuite, he won't get the required transitive dependencies, such as wagon or aether, so the resolver is unusable.
> According to disscussion with Vladimir, it would help "to flatten" dependency tree for ShrinkWrap dependency Resolver, however, that's only the part of the solution, the restrictions posed in AS7 parent must be relaxed afterwards.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 23:32:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 26 Jul 2011 23:32:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1403) Excluded/Banned
 transitive dependencies for Maven Dependency Resolver are too strict
In-Reply-To: <415854736.82382.1311685883624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2006545837.83778.1311737543654.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616618#comment-12616618 ] 

David Lloyd commented on AS7-1403:
----------------------------------

I also don't understand.  We've flattened transitive deps pretty much from day one.  It looks to me like the problem is simply that you're missing a dependency.

> Excluded/Banned transitive dependencies for Maven Dependency Resolver are too strict
> ------------------------------------------------------------------------------------
>
>                 Key: AS7-1403
>                 URL: https://issues.jboss.org/browse/AS7-1403
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Build System
>    Affects Versions: 7.0.0.Final
>            Reporter: Karel Piwko
>            Assignee: Paul Gier
>
> During 7.0.0.CR1 build, there was a decision to remove transitive dependencies from other projects and exclude/ban them in jboss-as-parent.
> This decision has effectively crippled usage of Maven Dependency Resolver, which wasn't used in CR1-date based testsuite, so the change passed silently. 
> If user wants to use the ShrinkWrap Dependency Resolver in the AS7 testsuite, he won't get the required transitive dependencies, such as wagon or aether, so the resolver is unusable.
> According to disscussion with Vladimir, it would help "to flatten" dependency tree for ShrinkWrap dependency Resolver, however, that's only the part of the solution, the restrictions posed in AS7 parent must be relaxed afterwards.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 23:37:23 2011
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Tue, 26 Jul 2011 23:37:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBBUILD-689) Add JGit
 repository to Maven repository
In-Reply-To: <1031274966.79166.1311588563657.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <777663927.83783.1311737843631.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBBUILD-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier updated JBBUILD-689:
------------------------------

         Assignee: Paul Gier
    Fix Version/s: Build Support 2011
      Description: 
Please add repository [1] to our Nexus instance. I'm using
this dependency in Arquillian OpenShift Express container and
having a extra repository defined in pom is not a way how we should do
it.

{code}
<repositories>
    <repository>
        <id>jgit-repository</id>
        <url>http://download.eclipse.org/jgit/maven</url>
    </repository>
</repositories>
{code}


  was:

Please add repository [1] to our Nexus instance. I'm using
this dependency in Arquillian OpenShift Express container and
having a extra repository defined in pom is not a way how we should do
it.

{code}
<repositories>
    <repository>
        <id>jgit-repository</id>
        <url>http://download.eclipse.org/jgit/maven</url>
    </repository>
</repositories>
{code}




What groupIds will be served from this repository?  I'm not able to browse it to see what is there.  Does it include valid checksums?

> Add JGit repository to Maven repository
> ---------------------------------------
>
>                 Key: JBBUILD-689
>                 URL: https://issues.jboss.org/browse/JBBUILD-689
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: Artifact Repositories
>            Reporter: Karel Piwko
>            Assignee: Paul Gier
>             Fix For: Build Support 2011
>
>
> Please add repository [1] to our Nexus instance. I'm using
> this dependency in Arquillian OpenShift Express container and
> having a extra repository defined in pom is not a way how we should do
> it.
> {code}
> <repositories>
>     <repository>
>         <id>jgit-repository</id>
>         <url>http://download.eclipse.org/jgit/maven</url>
>     </repository>
> </repositories>
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Tue Jul 26 23:58:23 2011
From: jira-events at lists.jboss.org (George Gastaldi (JIRA))
Date: Tue, 26 Jul 2011 23:58:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1177) Implement JavaMail
In-Reply-To: <371450412.33446.1309771103714.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <42310474.83788.1311739103738.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616620#comment-12616620 ] 

George Gastaldi commented on AS7-1177:
--------------------------------------

Don?t forget IMAP support also

> Implement JavaMail
> ------------------
>
>                 Key: AS7-1177
>                 URL: https://issues.jboss.org/browse/AS7-1177
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Modules
>    Affects Versions: 7.0.0.CR1
>            Reporter: Juergen Zimmermann
>            Assignee: Tomaz Cerar
>
> JavaMail cannot be used as it was in JBossAS 6 and earlier.
> 1) I tried as in JBoss 6:
> @Resource(mappedName = "java:Mail")
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:12:08,454 INFO  [org.jboss.as.server.controller] (pool-1-thread-48) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.naming.context.java.comp.\"test.ear\".test.KundenverwaltungListener.\"env/de.swe2.kundenverwaltung.service.KundenverwaltungListener/mailer\".jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.8","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Dao.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.ValidationService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Kundenverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Artikelverwaltung.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.FileStore.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.RolesService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.BestellverwaltungResourceImpl.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.PasswordService.START","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".jndiDependencyService","jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.Bestellverwaltung.START"]}
> 11:12:08,468 INFO  [org.jboss.jpa] (MSC service thread 1-1) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:12:08,470 INFO  [org.jboss.weld] (MSC service thread 1-1) Stopping weld service
> 2) I tried
> @Resource
> private Session mailer;
> ... and got this logging info within the Arquillian tests:
> 11:09:20,085 INFO  [org.jboss.as.server.controller] (pool-1-thread-46) Deployment of "test.ear.ear" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.subunit.\"test.ear.ear\".\"test.jar\".component.KundenverwaltungListener.START"]}
> 11:09:20,094 INFO  [org.jboss.jpa] (MSC service thread 1-2) stopping Persistence Unit Service 'test.ear.ear/test.jar#swe2Persistence' 
> 11:09:20,098 INFO  [org.jboss.weld] (MSC service thread 1-2) Stopping weld service

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Wed Jul 27 01:45:23 2011
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Wed, 27 Jul 2011 01:45:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3147) Regression: all
 uppercase field reference results in compile error
In-Reply-To: <2362491.70386.1311184103681.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1951683746.83850.1311745523734.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616625#comment-12616625 ] 

Wolfgang Laun commented on JBRULES-3147:
----------------------------------------

Report by 

this does not compile in 5.2.0 (OK in 5.0.1):
   Foo( MICompanyMarketClassification in (?2?, ?3?) )

this works in 5.2. but did not in 5.0.1:
   Foo( mICompanyMarketClassification in ... )

this works in 5.2:
   Foo( FHAMaxBaseMortgageWithToleranceAmt < (...) )




> Regression: all uppercase field reference results in compile error
> ------------------------------------------------------------------
>
>                 Key: JBRULES-3147
>                 URL: https://issues.jboss.org/browse/JBRULES-3147
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler (expert)
>    Affects Versions: 5.2.0.Final
>            Reporter: Wolfgang Laun
>            Assignee: Mark Proctor
>             Fix For: 5.2.1.Final
>
>
> Consider the following ways of writing getters, setters and pattern field names 
>   element  xetter    field  5.1.1   5.3.0
> =============================================
>   state    xetstate  state    OK     OK
>   state    xetState  state    OK     OK
>   staTe    xetStaTe  staTe    OK     OK
>   state    xetSTATE  STATE    OK     ERR
> The last variation is a regression from 5.1.1. It is not so absurd - if the field is designated with an acronym (XML,...) this would be the natural way to write xetters and the pattern field.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Wed Jul 27 01:49:23 2011
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Wed, 27 Jul 2011 01:49:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (JBRULES-3147)
 Regression: all uppercase field reference results in compile error
In-Reply-To: <2362491.70386.1311184103681.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1494960417.83854.1311745763658.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616625#comment-12616625 ] 

Wolfgang Laun edited comment on JBRULES-3147 at 7/27/11 1:47 AM:
-----------------------------------------------------------------

Report by Tom E. Murphy

this does not compile in 5.2.0 (OK in 5.0.1):
   Foo( MICompanyMarketClassification in (?2?, ?3?) )

this works in 5.2. but did not in 5.0.1:
   Foo( mICompanyMarketClassification in ... )

this works in 5.2:
   Foo( FHAMaxBaseMortgageWithToleranceAmt < (...) )




      was (Author: laune):
    Report by 

this does not compile in 5.2.0 (OK in 5.0.1):
   Foo( MICompanyMarketClassification in (?2?, ?3?) )

this works in 5.2. but did not in 5.0.1:
   Foo( mICompanyMarketClassification in ... )

this works in 5.2:
   Foo( FHAMaxBaseMortgageWithToleranceAmt < (...) )



  
> Regression: all uppercase field reference results in compile error
> ------------------------------------------------------------------
>
>                 Key: JBRULES-3147
>                 URL: https://issues.jboss.org/browse/JBRULES-3147
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler (expert)
>    Affects Versions: 5.2.0.Final
>            Reporter: Wolfgang Laun
>            Assignee: Mark Proctor
>             Fix For: 5.2.1.Final
>
>
> Consider the following ways of writing getters, setters and pattern field names 
>   element  xetter    field  5.1.1   5.3.0
> =============================================
>   state    xetstate  state    OK     OK
>   state    xetState  state    OK     OK
>   staTe    xetStaTe  staTe    OK     OK
>   state    xetSTATE  STATE    OK     ERR
> The last variation is a regression from 5.1.1. It is not so absurd - if the field is designated with an acronym (XML,...) this would be the natural way to write xetters and the pattern field.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Wed Jul 27 02:28:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Wed, 27 Jul 2011 02:28:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1400) Built-in JAX-RS
 providers registered twice
In-Reply-To: <335005987.82158.1311681923643.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1175803201.83950.1311748103636.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved AS7-1400.
---------------------------------

    Resolution: Done


Fixed

> Built-in JAX-RS providers registered twice
> ------------------------------------------
>
>                 Key: AS7-1400
>                 URL: https://issues.jboss.org/browse/AS7-1400
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 7.0.0.Final
>            Reporter: Jozef Hartinger
>            Assignee: Stuart Douglas
>             Fix For: 7.0.1.Final
>
>
> RESTEasy considers every JAX-RS provider listed in a service loader-like to be a built-in provider. RESTEasy take care of loading of these providers early in the startup. Once loaded, these providers are registered with "built-in" flag, which is important to guarantee that any custom provider is given priority over a built-in one at runtime. The registration is handled by the RegisterBuiltin class https://resteasy.svn.sourceforge.net/svnroot/resteasy/trunk/jaxrs/resteasy-jaxrs/src/main/java/org/jboss/resteasy/plugins/providers/RegisterBuiltin.java
> However, it seems that AS7 scans resteasy jars for providers and registers the built-in providers again - as application-provided providers. As a result, every built-in provider is registered twice. Once as built-in and once as application-provided provider. This has several consequences. Once of them is that the priority of application-provided providers is not guaranteed any longer.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 04:06:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 27 Jul 2011 04:06:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1276) When using
 Resteasy+Jackson jackson annotation are ignored
In-Reply-To: <1615132222.51870.1310606483884.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <672782136.84019.1311753983682.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated AS7-1276:
------------------------------

    Forum Reference: http://community.jboss.org/message/615052


> When using Resteasy+Jackson jackson annotation are ignored
> ----------------------------------------------------------
>
>                 Key: AS7-1276
>                 URL: https://issues.jboss.org/browse/AS7-1276
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Final
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 7.0.1.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 04:08:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 27 Jul 2011 04:08:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1408) Missing
 module-dependency breacks reconfiguring jackson ObjectMapper with using
 resteasy-jackson-provider
In-Reply-To: <410650910.82917.1311695243605.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <629763156.84023.1311754103690.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616636#comment-12616636 ] 

jaikiran pai commented on AS7-1408:
-----------------------------------

I think this is already fixed in AS7 upstream as part of https://issues.jboss.org/browse/AS7-1276. Please try the latest AS7 nightly build http://community.jboss.org/thread/167590


> Missing module-dependency breacks reconfiguring jackson ObjectMapper with using resteasy-jackson-provider
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1408
>                 URL: https://issues.jboss.org/browse/AS7-1408
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Modules
>    Affects Versions: 7.0.0.Final
>            Reporter: Sebastian Jancke
>            Assignee: David Lloyd
>              Labels: classloader, resteasy
>
> When using resteasy with resteasy-jackson-provider, classloading from jackson-xc to jackson-core-asl is not working because the module-dependency is missing.
> Stacktrace:
> 17:12:24,479 WARN  [org.jboss.modules] (MSC service thread 1-8) Failed to define class org.codehaus.jackson.xc.JaxbAnnotationIntrospector in Module "org.codehaus.jackson.jackson-xc:main" from local module loader @4ce66f56 (roots: OBFUSCATED\jboss-as-7.0.0.Final\modules): java.lang.LinkageError: Failed
>  to link org/codehaus/jackson/xc/JaxbAnnotationIntrospector (Module "org.codehaus.jackson.jackson-xc:main" from local module loader @4ce66f56 (roots:
>  OBFUSCATED\jboss-as-7.0.0.Final\modules))
>         at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:401)
>         at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261)
>         at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76)
>         at org.jboss.modules.Module.loadModuleClass(Module.java:588)
>         at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:183)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
>         at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
>         at java.lang.Class.getDeclaredFields0(Native Method) [:1.6.0_24]
>         at java.lang.Class.privateGetDeclaredFields(Class.java:2291) [:1.6.0_24]
>         at java.lang.Class.getDeclaredFields(Class.java:1743) [:1.6.0_24]
>         at org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:116) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:112) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:67) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at org.jboss.weld.util.reflection.SecureReflections.getDeclaredFields(SecureReflections.java:111) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:163) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:124) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:54) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:42) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at com.google.common.collect.ComputingConcurrentHashMap.compute(ComputingConcurrentHashMap.java:206) [guava-r07.jar:]
>         at com.google.common.collect.ComputingConcurrentHashMap.apply(ComputingConcurrentHashMap.java:100) [guava-r07.jar:]
>         at com.google.common.collect.MapMaker$ComputingMapAdapter.get(MapMaker.java:515) [guava-r07.jar:]
>         at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:183) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:96) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:133) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:191) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:368) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:81) [jboss-as-weld-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.as.weld.services.WeldService.start(WeldService.java:89) [jboss-as-weld-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
>         at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
>         at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
> Caused by: java.lang.NoClassDefFoundError: org/codehaus/jackson/Versioned
>         at java.lang.ClassLoader.defineClass1(Native Method) [:1.6.0_24]
>         at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) [:1.6.0_24]
>         at java.lang.ClassLoader.defineClass(ClassLoader.java:616) [:1.6.0_24]
>         at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) [:1.6.0_24]
>         at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:397)
>         ... 35 more
> Caused by: java.lang.ClassNotFoundException: org.codehaus.jackson.Versioned from [Module "org.codehaus.jackson.jackson-xc:main" from local module loader @4ce66f56 (roots: OBFUSCATED\jboss-as-7.0.0.Final\modules)]
>         at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
>         at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
>         ... 40 more
> FIX [module org.codehaus.jackson.jackson-xc]
> <module xmlns="urn:jboss:module:1.0" name="org.codehaus.jackson.jackson-xc">
>   <resources>
>     <resource-root path="jackson-xc-1.6.3.jar"/>
>         <!-- Insert resources here -->
>   </resources>
>   <dependencies>
>       <module name="javax.api" />
>       <module name="javax.activation.api" />
>       <module name="javax.xml.bind.api" />
>       <module name="org.codehaus.jackson.jackson-mapper-asl" />
>       <module name="org.codehaus.jackson.jackson-core-asl" />
>   </dependencies>
> </module>

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 04:10:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 27 Jul 2011 04:10:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1404) Messaging
 Subsystem: Naming inconsistency
In-Reply-To: <1804074427.82591.1311689543720.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2002484050.84027.1311754224060.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616637#comment-12616637 ] 

jaikiran pai commented on AS7-1404:
-----------------------------------

I'm working on fixing this in AS7-1210. I'll mark this as a duplicate.


> Messaging Subsystem: Naming inconsistency
> -----------------------------------------
>
>                 Key: AS7-1404
>                 URL: https://issues.jboss.org/browse/AS7-1404
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management, JMS
>    Affects Versions: 7.0.0.Final
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 7.0.1.Final
>
>
> it seems the messaging subsystem prepends the "java:/" namespace to it JNDI names.
> This is not the case for other subsystems and should be treated consistently:
> I.e trying to add a queue 'java:/jboss/queues/myQueue' leads to:
> {noformat}
> 16:07:54,288 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.naming.context.java.java:/jboss/queues/myQueue: org.jboss.msc.service.StartException in service jboss.naming.context.java.java:/jboss/queues/myQueue: Failed to bind resource into naming store [org.jboss.as.naming.InMemoryNamingStore at 4f3ad88b] at location [jboss/queues/myQueue]
> 	at org.jboss.as.naming.service.BinderService.start(BinderService.java:113)
> 	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_26]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
> 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> {noformat} 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 04:14:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 27 Jul 2011 04:14:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1404) Messaging Subsystem:
 Naming inconsistency
In-Reply-To: <1804074427.82591.1311689543720.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <547044352.84032.1311754463713.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved AS7-1404.
-------------------------------

    Fix Version/s:     (was: 7.0.1.Final)
       Resolution: Duplicate Issue


Duplicate of AS7-1210

> Messaging Subsystem: Naming inconsistency
> -----------------------------------------
>
>                 Key: AS7-1404
>                 URL: https://issues.jboss.org/browse/AS7-1404
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management, JMS
>    Affects Versions: 7.0.0.Final
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>
> it seems the messaging subsystem prepends the "java:/" namespace to it JNDI names.
> This is not the case for other subsystems and should be treated consistently:
> I.e trying to add a queue 'java:/jboss/queues/myQueue' leads to:
> {noformat}
> 16:07:54,288 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.naming.context.java.java:/jboss/queues/myQueue: org.jboss.msc.service.StartException in service jboss.naming.context.java.java:/jboss/queues/myQueue: Failed to bind resource into naming store [org.jboss.as.naming.InMemoryNamingStore at 4f3ad88b] at location [jboss/queues/myQueue]
> 	at org.jboss.as.naming.service.BinderService.start(BinderService.java:113)
> 	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_26]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
> 	at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
> {noformat} 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 04:18:24 2011
From: jira-events at lists.jboss.org (David Bosschaert (JIRA))
Date: Wed, 27 Jul 2011 04:18:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1409) Expose OSGi subsystem
 configuration through console
Message-ID: <629786346.84058.1311754704301.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Expose OSGi subsystem configuration through console
---------------------------------------------------

                 Key: AS7-1409
                 URL: https://issues.jboss.org/browse/AS7-1409
             Project: Application Server 7
          Issue Type: Sub-task
          Components: Console
            Reporter: David Bosschaert
            Assignee: David Bosschaert
             Fix For: 7.1.0.CR1


The configuration of the OSGi subsystem (urn:jboss:domain:osgi:1.0) should be manageable through the console.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 04:22:23 2011
From: jira-events at lists.jboss.org (David Bosschaert (JIRA))
Date: Wed, 27 Jul 2011 04:22:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1410) Expose runtime OSGi
 management configuration through console
Message-ID: <145027417.84077.1311754943682.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Expose runtime OSGi management configuration through console
------------------------------------------------------------

                 Key: AS7-1410
                 URL: https://issues.jboss.org/browse/AS7-1410
             Project: Application Server 7
          Issue Type: Sub-task
          Components: Console
            Reporter: David Bosschaert
            Assignee: David Bosschaert
             Fix For: 7.1.0.CR1


Bundle runtime management should be exposed through the console.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 04:35:23 2011
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 27 Jul 2011 04:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-1346) Update documentation
In-Reply-To: <1720745363.62235.1311069143787.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1348737181.84109.1311755723895.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1346.
----------------------------

    Resolution: Done


> Update documentation
> --------------------
>
>                 Key: JGRP-1346
>                 URL: https://issues.jboss.org/browse/JGRP-1346
>             Project: JGroups
>          Issue Type: Sub-task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>
> javadocs, manual, tutorial

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 04:35:24 2011
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 27 Jul 2011 04:35:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-1342) Documentation:
 create a separate javadoc / manual / tutorial version for the 3.x branch
In-Reply-To: <846151172.30101.1309445483655.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1206538232.84120.1311755724373.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1342.
----------------------------

    Resolution: Done


> Documentation: create a separate javadoc / manual / tutorial version for the 3.x branch
> ---------------------------------------------------------------------------------------
>
>                 Key: JGRP-1342
>                 URL: https://issues.jboss.org/browse/JGRP-1342
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.0
>
>
> Since there are quite a few API changes, create a separate set of documentation artifacts (javadocs, manual, tutorial) for 3.x. This is mainly a question of how and where we store the docs on the website (jgroups.org)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 04:47:23 2011
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Wed, 27 Jul 2011 04:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-275) Allow for sub
 deployment to have declarative structure
In-Reply-To: <632681343.470.1308058349656.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <729677382.84162.1311756443664.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBDEPLOY-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin resolved JBDEPLOY-275.
----------------------------------

    Resolution: Done


> Allow for sub deployment to have declarative structure 
> -------------------------------------------------------
>
>                 Key: JBDEPLOY-275
>                 URL: https://issues.jboss.org/browse/JBDEPLOY-275
>             Project: JBoss Deployers
>          Issue Type: Task
>    Affects Versions: JBDEPLOY-2.2.1.GA
>            Reporter: Ales Justin
>            Assignee: Ales Justin
>             Fix For: JBDEPLOY-2.2.2.GA
>
>
> Currently jboss-structure.xml can only be used on the top level deployment.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 04:52:23 2011
From: jira-events at lists.jboss.org (Rado Panak (JIRA))
Date: Wed, 27 Jul 2011 04:52:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-9416) EJB3 SFSB
 performace problem: parallel calls are sequenced
In-Reply-To: <1327573270.53690.1310651003625.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <888694288.84171.1311756743830.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBAS-9416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616648#comment-12616648 ] 

Rado Panak commented on JBAS-9416:
----------------------------------

Hi,
I can confirm this problem on our deployment in AS6. It becomes really a big performance problem for us.

> EJB3 SFSB performace problem: parallel calls are sequenced
> ----------------------------------------------------------
>
>                 Key: JBAS-9416
>                 URL: https://issues.jboss.org/browse/JBAS-9416
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Radim Hanus
>            Assignee: jaikiran pai
>         Attachments: jboss-5.1_server.log, jboss-6.0_server.log, sfsbtest.zip, thread_dump.txt
>
>
> When a client looks up more SFSB of given type in dedicated threads and subsequently calls business methods then such calls are always sequenced.
> Works fine in jboss-5.1.0

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 04:52:23 2011
From: jira-events at lists.jboss.org (David Bosschaert (JIRA))
Date: Wed, 27 Jul 2011 04:52:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1411) Tattletale errors in
	OSGi layer
Message-ID: <1549913440.84172.1311756743860.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Tattletale errors in OSGi layer
-------------------------------

                 Key: AS7-1411
                 URL: https://issues.jboss.org/browse/AS7-1411
             Project: Application Server 7
          Issue Type: Task
          Components: OSGi
            Reporter: David Bosschaert
            Assignee: Thomas Diesler


>From Jesper Pedersen:

There are a lot of ERRORs from the OSGi layer...

To run: java -jar tattletale.jar jboss-7.0.0.Final/ as7 

You can also observer the tattletale report on Jenkins here: https://hudson.mw.lab.eng.bos.redhat.com/hudson/view/JBoss%20AS/job/JBoss-AS-7.0.x-TattleTale/

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 04:55:23 2011
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 27 Jul 2011 04:55:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3156) Singe HTML
 documentation (of Drools Expert) is broken from chapter 5 's first SVG
 image (in section railroad diagrams) onwards on firefox 5 beta 1
Message-ID: <1264800918.84180.1311756923624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Singe HTML documentation (of Drools Expert) is broken from chapter 5 's first SVG image (in section railroad diagrams) onwards on firefox 5 beta 1
--------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-3156
                 URL: https://issues.jboss.org/browse/JBRULES-3156
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Geoffrey De Smet
            Assignee: Geoffrey De Smet
            Priority: Critical
             Fix For: 5.2.1.Final


"Having a look at it with the html-tidy plugin from firefox there are several </span> tags which are too many and more likely the object tags are not closed correctly (you use xhtml so you need to close then with </object> the empty tag structure <object/> is invalid in xhtml)."

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 05:08:23 2011
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Wed, 27 Jul 2011 05:08:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1379) Provide the ability
 to update RA attributes
In-Reply-To: <1278138426.76165.1311338604308.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1039103247.84186.1311757703784.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616649#comment-12616649 ] 

Jeff Zhang commented on AS7-1379:
---------------------------------

Hi Jesper,

Currently transaction-support is readonly.
[standalone at localhost:9999 resource-adapter=xmpp-ra.rar] :write-attribute(name=transaction-support,value=Notransaction) 
{
    "outcome" => "failed",
    "failure-description" => "Attribute transaction-support is not writeable",
    "rolled-back" => true
}

This should be modifiable from cli or console?
So far, we have some RWHandler to support read-write properties about pool. Should we make every properties modifiable?

> Provide the ability to update RA attributes
> -------------------------------------------
>
>                 Key: AS7-1379
>                 URL: https://issues.jboss.org/browse/AS7-1379
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.Beta1
>
>
> most of the attributes seem to be read only.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 05:16:24 2011
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 27 Jul 2011 05:16:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3156) Singe HTML
 documentation (of Drools Expert) is broken from chapter 5 's first SVG
 image (in section railroad diagrams) onwards on firefox 5 beta 1
In-Reply-To: <1264800918.84180.1311756923624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1420169239.84215.1311758184176.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616652#comment-12616652 ] 

Geoffrey De Smet commented on JBRULES-3156:
-------------------------------------------

Looks like there are many xml violations. This isn't valid xhtml at all:

{code}
<pre>
<span>foo</span>
</span>
</pre>
{code}

> Singe HTML documentation (of Drools Expert) is broken from chapter 5 's first SVG image (in section railroad diagrams) onwards on firefox 5 beta 1
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3156
>                 URL: https://issues.jboss.org/browse/JBRULES-3156
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Critical
>             Fix For: 5.2.1.Final
>
>
> "Having a look at it with the html-tidy plugin from firefox there are several </span> tags which are too many and more likely the object tags are not closed correctly (you use xhtml so you need to close then with </object> the empty tag structure <object/> is invalid in xhtml)."

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 05:18:24 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 27 Jul 2011 05:18:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1379) Provide the ability
 to update RA attributes
In-Reply-To: <1278138426.76165.1311338604308.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1213704043.84229.1311758304073.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616654#comment-12616654 ] 

Heiko Braun commented on AS7-1379:
----------------------------------

Not all of these changes need to be applied at runtime, some may require server restart. Still it should be possible to modify them (just the config, not the runtime state). However if the changes to can be applied to the runtime immediately , fine. But it's not a requirement for making the config r/w. Same applies to AS7-1381

> Provide the ability to update RA attributes
> -------------------------------------------
>
>                 Key: AS7-1379
>                 URL: https://issues.jboss.org/browse/AS7-1379
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.Beta1
>
>
> most of the attributes seem to be read only.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 05:28:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 27 Jul 2011 05:28:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1381) Make RA config
 properties sub resources
In-Reply-To: <796812033.76172.1311338604471.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1753935531.84265.1311758903874.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616658#comment-12616658 ] 

Heiko Braun commented on AS7-1381:
----------------------------------

Take an example RA config:

{noformat}
 "result" => {
        "archive" => "xmpp-ra.rar",
        "background-validation" => undefined,
        "background-validation-minutes" => undefined,
        "blocking-timeout-wait-millis" => undefined,
        "config-properties" => [
            ("host" => "talk.google.com"),
            ("port" => "5222")
        ],
        "connection-definitions" => [{
            "class-name" => "com.ramphastos.xmpp.XmppConnectionFactory",
            "jndi-name" => "java:jboss/eis/xmpp",
            "pool-name" => "xmpp-ra_rar-Pool"
        }],
        "idle-timeout-minutes" => undefined,
        "max-pool-size" => undefined,
        "min-pool-size" => undefined,
        "pool-prefill" => undefined,
        "pool-use-strict-min" => undefined,
        "transaction-support" => "NoTransaction",
        "use-fast-fail" => undefined
    }

{noformat}

I cannot update "connection-definitions" or "config-properties" through the management API, because they are not addressable. System properties are a good example how it should be done to prevent this problem:

{noformat}
[standalone at localhost:9999 /] /host=master:read-resource
{
    "outcome" => "success",
    "result" => {
        "domain-controller" => {"local" => {}},
        "extension" => undefined,
        "name" => "master",
        "namespaces" => [],
        "path" => undefined,
        "schema-locations" => [],
        "core-service" => {"management" => undefined},
        "interface" => {
            "public" => undefined,
            "management" => undefined
        },
        "jvm" => {"default" => undefined},
        "server" => {
            "server-one" => undefined,
            "server-two" => undefined
        },
        "server-config" => {
            "server-one" => undefined,
            "server-two" => undefined,
            "server-three" => undefined
        },
        "system-property" => {
            "propertyTwo" => undefined,
            "porpertyOne" => undefined
        }
    }
}

{noformat}

As you can see the system-properties sub resources (property lists) that can be addressed and thus modified on their own:

{norformat}

// read
[standalone at localhost:9999 /] /host=master/system-property=propertyTwo:read-resource
{
    "outcome" => "success",
    "result" => {
        "boot-time" => false,
        "value" => "twoValue"
    }
}

// remove
[standalone at localhost:9999 /] /host=master/system-property=propertyTwo:remove

// write
[standalone at localhost:9999 /] /host=master/system-property=someProp:add(value=test)
{noformat}





> Make RA config properties sub resources
> ---------------------------------------
>
>                 Key: AS7-1381
>                 URL: https://issues.jboss.org/browse/AS7-1381
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.CR1
>
>
> Take a look how system properties are represented. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 05:28:24 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 27 Jul 2011 05:28:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-1381) Make RA
 config properties sub resources
In-Reply-To: <796812033.76172.1311338604471.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1172829512.84271.1311758904394.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616658#comment-12616658 ] 

Heiko Braun edited comment on AS7-1381 at 7/27/11 5:27 AM:
-----------------------------------------------------------

Take an example RA config:

{noformat}
 "result" => {
        "archive" => "xmpp-ra.rar",
        "background-validation" => undefined,
        "background-validation-minutes" => undefined,
        "blocking-timeout-wait-millis" => undefined,
        "config-properties" => [
            ("host" => "talk.google.com"),
            ("port" => "5222")
        ],
        "connection-definitions" => [{
            "class-name" => "com.ramphastos.xmpp.XmppConnectionFactory",
            "jndi-name" => "java:jboss/eis/xmpp",
            "pool-name" => "xmpp-ra_rar-Pool"
        }],
        "idle-timeout-minutes" => undefined,
        "max-pool-size" => undefined,
        "min-pool-size" => undefined,
        "pool-prefill" => undefined,
        "pool-use-strict-min" => undefined,
        "transaction-support" => "NoTransaction",
        "use-fast-fail" => undefined
    }

{noformat}

I cannot update "connection-definitions" or "config-properties" through the management API, because they are not addressable. System properties are a good example how it should be done to prevent this problem:

{noformat}
[standalone at localhost:9999 /] /host=master:read-resource
{
    "outcome" => "success",
    "result" => {
        "domain-controller" => {"local" => {}},
        "extension" => undefined,
        "name" => "master",
        "namespaces" => [],
        "path" => undefined,
        "schema-locations" => [],
        "core-service" => {"management" => undefined},
        "interface" => {
            "public" => undefined,
            "management" => undefined
        },
        "jvm" => {"default" => undefined},
        "server" => {
            "server-one" => undefined,
            "server-two" => undefined
        },
        "server-config" => {
            "server-one" => undefined,
            "server-two" => undefined,
            "server-three" => undefined
        },
        "system-property" => {
            "propertyTwo" => undefined,
            "porpertyOne" => undefined
        }
    }
}

{noformat}

As you can see the system-properties are sub resources (property lists) that can be addressed and thus modified on their own:

{norformat}

// read
[standalone at localhost:9999 /] /host=master/system-property=propertyTwo:read-resource
{
    "outcome" => "success",
    "result" => {
        "boot-time" => false,
        "value" => "twoValue"
    }
}

// remove
[standalone at localhost:9999 /] /host=master/system-property=propertyTwo:remove

// write
[standalone at localhost:9999 /] /host=master/system-property=someProp:add(value=test)
{noformat}





      was (Author: heiko.braun):
    Take an example RA config:

{noformat}
 "result" => {
        "archive" => "xmpp-ra.rar",
        "background-validation" => undefined,
        "background-validation-minutes" => undefined,
        "blocking-timeout-wait-millis" => undefined,
        "config-properties" => [
            ("host" => "talk.google.com"),
            ("port" => "5222")
        ],
        "connection-definitions" => [{
            "class-name" => "com.ramphastos.xmpp.XmppConnectionFactory",
            "jndi-name" => "java:jboss/eis/xmpp",
            "pool-name" => "xmpp-ra_rar-Pool"
        }],
        "idle-timeout-minutes" => undefined,
        "max-pool-size" => undefined,
        "min-pool-size" => undefined,
        "pool-prefill" => undefined,
        "pool-use-strict-min" => undefined,
        "transaction-support" => "NoTransaction",
        "use-fast-fail" => undefined
    }

{noformat}

I cannot update "connection-definitions" or "config-properties" through the management API, because they are not addressable. System properties are a good example how it should be done to prevent this problem:

{noformat}
[standalone at localhost:9999 /] /host=master:read-resource
{
    "outcome" => "success",
    "result" => {
        "domain-controller" => {"local" => {}},
        "extension" => undefined,
        "name" => "master",
        "namespaces" => [],
        "path" => undefined,
        "schema-locations" => [],
        "core-service" => {"management" => undefined},
        "interface" => {
            "public" => undefined,
            "management" => undefined
        },
        "jvm" => {"default" => undefined},
        "server" => {
            "server-one" => undefined,
            "server-two" => undefined
        },
        "server-config" => {
            "server-one" => undefined,
            "server-two" => undefined,
            "server-three" => undefined
        },
        "system-property" => {
            "propertyTwo" => undefined,
            "porpertyOne" => undefined
        }
    }
}

{noformat}

As you can see the system-properties sub resources (property lists) that can be addressed and thus modified on their own:

{norformat}

// read
[standalone at localhost:9999 /] /host=master/system-property=propertyTwo:read-resource
{
    "outcome" => "success",
    "result" => {
        "boot-time" => false,
        "value" => "twoValue"
    }
}

// remove
[standalone at localhost:9999 /] /host=master/system-property=propertyTwo:remove

// write
[standalone at localhost:9999 /] /host=master/system-property=someProp:add(value=test)
{noformat}




  
> Make RA config properties sub resources
> ---------------------------------------
>
>                 Key: AS7-1381
>                 URL: https://issues.jboss.org/browse/AS7-1381
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.CR1
>
>
> Take a look how system properties are represented. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 05:28:25 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 27 Jul 2011 05:28:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-1381) Make RA
 config properties sub resources
In-Reply-To: <796812033.76172.1311338604471.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1927905720.84276.1311758905243.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616658#comment-12616658 ] 

Heiko Braun edited comment on AS7-1381 at 7/27/11 5:27 AM:
-----------------------------------------------------------

Take an example RA config:

{noformat}
 "result" => {
        "archive" => "xmpp-ra.rar",
        "background-validation" => undefined,
        "background-validation-minutes" => undefined,
        "blocking-timeout-wait-millis" => undefined,
        "config-properties" => [
            ("host" => "talk.google.com"),
            ("port" => "5222")
        ],
        "connection-definitions" => [{
            "class-name" => "com.ramphastos.xmpp.XmppConnectionFactory",
            "jndi-name" => "java:jboss/eis/xmpp",
            "pool-name" => "xmpp-ra_rar-Pool"
        }],
        "idle-timeout-minutes" => undefined,
        "max-pool-size" => undefined,
        "min-pool-size" => undefined,
        "pool-prefill" => undefined,
        "pool-use-strict-min" => undefined,
        "transaction-support" => "NoTransaction",
        "use-fast-fail" => undefined
    }

{noformat}

I cannot update "connection-definitions" or "config-properties" through the management API, because they are not addressable. System properties are a good example how it should be done to prevent this problem:

{noformat}
[standalone at localhost:9999 /] /host=master:read-resource
{
    "outcome" => "success",
    "result" => {
        "domain-controller" => {"local" => {}},
        "extension" => undefined,
        "name" => "master",
        "namespaces" => [],
        "path" => undefined,
        "schema-locations" => [],
        "core-service" => {"management" => undefined},
        "interface" => {
            "public" => undefined,
            "management" => undefined
        },
        "jvm" => {"default" => undefined},
        "server" => {
            "server-one" => undefined,
            "server-two" => undefined
        },
        "server-config" => {
            "server-one" => undefined,
            "server-two" => undefined,
            "server-three" => undefined
        },
        "system-property" => {
            "propertyTwo" => undefined,
            "porpertyOne" => undefined
        }
    }
}

{noformat}

As you can see the system-properties are sub resources (property lists) that can be addressed and thus modified on their own:

{noformat}

// read
[standalone at localhost:9999 /] /host=master/system-property=propertyTwo:read-resource
{
    "outcome" => "success",
    "result" => {
        "boot-time" => false,
        "value" => "twoValue"
    }
}

// remove
[standalone at localhost:9999 /] /host=master/system-property=propertyTwo:remove

// write
[standalone at localhost:9999 /] /host=master/system-property=someProp:add(value=test)
{noformat}





      was (Author: heiko.braun):
    Take an example RA config:

{noformat}
 "result" => {
        "archive" => "xmpp-ra.rar",
        "background-validation" => undefined,
        "background-validation-minutes" => undefined,
        "blocking-timeout-wait-millis" => undefined,
        "config-properties" => [
            ("host" => "talk.google.com"),
            ("port" => "5222")
        ],
        "connection-definitions" => [{
            "class-name" => "com.ramphastos.xmpp.XmppConnectionFactory",
            "jndi-name" => "java:jboss/eis/xmpp",
            "pool-name" => "xmpp-ra_rar-Pool"
        }],
        "idle-timeout-minutes" => undefined,
        "max-pool-size" => undefined,
        "min-pool-size" => undefined,
        "pool-prefill" => undefined,
        "pool-use-strict-min" => undefined,
        "transaction-support" => "NoTransaction",
        "use-fast-fail" => undefined
    }

{noformat}

I cannot update "connection-definitions" or "config-properties" through the management API, because they are not addressable. System properties are a good example how it should be done to prevent this problem:

{noformat}
[standalone at localhost:9999 /] /host=master:read-resource
{
    "outcome" => "success",
    "result" => {
        "domain-controller" => {"local" => {}},
        "extension" => undefined,
        "name" => "master",
        "namespaces" => [],
        "path" => undefined,
        "schema-locations" => [],
        "core-service" => {"management" => undefined},
        "interface" => {
            "public" => undefined,
            "management" => undefined
        },
        "jvm" => {"default" => undefined},
        "server" => {
            "server-one" => undefined,
            "server-two" => undefined
        },
        "server-config" => {
            "server-one" => undefined,
            "server-two" => undefined,
            "server-three" => undefined
        },
        "system-property" => {
            "propertyTwo" => undefined,
            "porpertyOne" => undefined
        }
    }
}

{noformat}

As you can see the system-properties are sub resources (property lists) that can be addressed and thus modified on their own:

{norformat}

// read
[standalone at localhost:9999 /] /host=master/system-property=propertyTwo:read-resource
{
    "outcome" => "success",
    "result" => {
        "boot-time" => false,
        "value" => "twoValue"
    }
}

// remove
[standalone at localhost:9999 /] /host=master/system-property=propertyTwo:remove

// write
[standalone at localhost:9999 /] /host=master/system-property=someProp:add(value=test)
{noformat}




  
> Make RA config properties sub resources
> ---------------------------------------
>
>                 Key: AS7-1381
>                 URL: https://issues.jboss.org/browse/AS7-1381
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.CR1
>
>
> Take a look how system properties are represented. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 05:30:23 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 27 Jul 2011 05:30:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1381) Make RA config
 properties sub resources
In-Reply-To: <796812033.76172.1311338604471.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1306642251.84289.1311759023745.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616660#comment-12616660 ] 

Heiko Braun commented on AS7-1381:
----------------------------------

For resource adapter this would result in a representation like:

{noformat}

// read value
/subsystem=resource-adapters/resource-adapter=xmpp-ra.rar/config-property=host:read-resource

// remove 

/subsystem=resource-adapters/resource-adapter=xmpp-ra.rar/config-property=host:remove

{noformat}

> Make RA config properties sub resources
> ---------------------------------------
>
>                 Key: AS7-1381
>                 URL: https://issues.jboss.org/browse/AS7-1381
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.CR1
>
>
> Take a look how system properties are represented. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 05:32:24 2011
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 27 Jul 2011 05:32:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1381) Make RA config
 properties sub resources
In-Reply-To: <796812033.76172.1311338604471.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1952525656.84297.1311759144073.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616661#comment-12616661 ] 

Heiko Braun commented on AS7-1381:
----------------------------------

See also:

- http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/003315.html
- http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/003350.html

> Make RA config properties sub resources
> ---------------------------------------
>
>                 Key: AS7-1381
>                 URL: https://issues.jboss.org/browse/AS7-1381
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.CR1
>
>
> Take a look how system properties are represented. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 05:32:24 2011
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Wed, 27 Jul 2011 05:32:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1352) JCA thread pools
 must be blocking
In-Reply-To: <29744231.69171.1311168323839.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1559755470.84300.1311759144350.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616662#comment-12616662 ] 

Jeff Zhang commented on AS7-1352:
---------------------------------

Hi Jesper,

Please help me to review the fix:
https://github.com/jeffzhang/jboss-as/commit/dce426a2128dd78e38072278d388703ea961f47a

Since parser use the code ThreadsParser from thread subsystem, I overwrite blocking attribute to true after parsing.

Thanks

> JCA thread pools must be blocking
> ---------------------------------
>
>                 Key: AS7-1352
>                 URL: https://issues.jboss.org/browse/AS7-1352
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 7.0.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.Alpha1
>
>
> The "blocking" attribute for the JCA thread pools should be ignored as it should always be true.
> In order to align with other subsystems we will just ignore any value set by the user, and hard code to true.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 06:27:23 2011
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Wed, 27 Jul 2011 06:27:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3152) Control of
 KnowledgeAgent instances
In-Reply-To: <413611220.80127.1311607043970.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <438629980.84568.1311762443772.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-3152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616679#comment-12616679 ] 

Davide Sottara commented on JBRULES-3152:
-----------------------------------------

How do you manage the KA lifecycle?
The user is expected to control the monitoring threads:

ResourceFactory.getResourceChangeNotifierService().start()/stop();
ResourceFactory.getResourceChangeScannerService().start()/stop();

and to dispose the KA when no longer needed:

kAgent.dispose();

-----------------------

At the moment, the KA name is not unique and they are not tracked. Could you provide a few more details on your use case so I can see if it is necessary/reasonable to implement an agent registry?

> Control of KnowledgeAgent instances
> -----------------------------------
>
>                 Key: JBRULES-3152
>                 URL: https://issues.jboss.org/browse/JBRULES-3152
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.2.0.Final
>            Reporter: Burkhard Vogel
>            Assignee: Mark Proctor
>
> There should be a way limit the number of KA on a server - as I restart test-clients and redeploy my client apps they tend to accumulate. Shouldn't the KA name be unique and any reference to a KA with the same name recover the already created KA? Or shouldn't all KA created by a client app (web or standalone) die when the creating app terminates?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 06:32:23 2011
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Wed, 27 Jul 2011 06:32:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-270) Intermittent
 failure of undeploy
In-Reply-To: <199739023.3169.1299196425630.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1116067960.84571.1311762743755.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBDEPLOY-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616680#comment-12616680 ] 

Ales Justin commented on JBDEPLOY-270:
--------------------------------------

I fail to see how it's an unordered Set issue?

It might just be a result of JBDEPLOY-184, 
which we had a long discussion on how to fix it, w/o obvious conclusions.


> Intermittent failure of undeploy
> --------------------------------
>
>                 Key: JBDEPLOY-270
>                 URL: https://issues.jboss.org/browse/JBDEPLOY-270
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions:  JBDEPLOY-2.0.10.GA 
>            Reporter: Dennis Reed
>         Attachments: JBDEPLOY-270-jboss-beans.xml
>
>
> When components are deployed, they are assigned names with a number appended based on the order it was processed.
> For example "jboss.deployment:id="dennis$defaultEvictionRegionConfig#1",type=Component"
> The number is assigned in (line #'s are from EAP 5.0):
>     at org.jboss.beans.metadata.plugins.AbstractBeanMetaData.setName(AbstractBeanMetaData.java:360)
>     at org.jboss.beans.metadata.plugins.NestedBeanHandler.checkForNestedBeans(NestedBeanHandler.java:77)
>     at org.jboss.beans.metadata.plugins.AbstractBeanMetaData.getBeans(AbstractBeanMetaData.java:202)
>     at org.jboss.kernel.plugins.deployment.AbstractKernelDeployment.getBeans(AbstractKernelDeployment.java:233)
>     at org.jboss.deployers.vfs.deployer.kernel.KernelDeploymentDeployer$KernelDeploymentVisitor.getBeans(KernelDeploymentDeployer.java:63)
>     at org.jboss.deployers.vfs.deployer.kernel.KernelDeploymentDeployer$KernelDeploymentVisitor.getBeans(KernelDeploymentDeployer.java:54)
>     at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryVisitor.deploy(BeanMetaDataFactoryVisitor.java:118)
> However, the beans are *not* processed in the same order every time.
> And they are processed separately during deployment and undeployment.
> This means that "myBean#1" may get deployed, but "myBean#2" is undeployed (leaving "myBean#1" still deployed).
> Subsequent deployments will fail with errors:
> 17:34:30,630 WARN  [AbstractDeploymentContext] Unable to register deployment mbean dennis$defaultEvictionRegionConfig#1
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="dennis$defaultEvictionRegionConfig#1",type=Component already registered.
> The root cause appears to be that the XML descriptor is read with jboss-xb using a Set (unordered), but then 
> this code has a dependency on the order being consistent between deploy and undeploy.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 06:48:23 2011
From: jira-events at lists.jboss.org (Karel Piwko (JIRA))
Date: Wed, 27 Jul 2011 06:48:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1403) Excluded/Banned
 transitive dependencies for Maven Dependency Resolver are too strict
In-Reply-To: <415854736.82382.1311685883624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <487428465.84580.1311763703760.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616682#comment-12616682 ] 

Karel Piwko commented on AS7-1403:
----------------------------------

I'll try to reword that:

ShrinkWrap Dependency Resolver (SWR) dependencies were not flattened and shrinkwrap-resolver-impl-maven got to the jboss-as-parent bom as a part of ShrinkWrap project. 

If user wants to use SWR in AS7, he has to add all its dependencies manually, as its dependencies were excluded and banned. These excluded dependencies are required for SWR to run, but nobody mentioned that because at time of the excluded/banned list creation this library was not used in any tests.

My point is that it would make much more sense:

1/ Use SWR as an external utility, e.g. not mentioned in jboss-as-parent at all. This way user can simply include only shrinkwrap-resolver-impl-maven at place where he wants to use it

2/ If dependency control is requirement, I can flatten shrinkwrap-resolver-impl end explicitly enumerate all required dependecies there. Then jboss-as-parent will have to be modified (e.g. remove excludes from shrinkwrap-resolver-impl). This way user can simply include shrinkwrap-resolver-impl-amven at place where you wants to use it and you get the dependency control.




> Excluded/Banned transitive dependencies for Maven Dependency Resolver are too strict
> ------------------------------------------------------------------------------------
>
>                 Key: AS7-1403
>                 URL: https://issues.jboss.org/browse/AS7-1403
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Build System
>    Affects Versions: 7.0.0.Final
>            Reporter: Karel Piwko
>            Assignee: Paul Gier
>
> During 7.0.0.CR1 build, there was a decision to remove transitive dependencies from other projects and exclude/ban them in jboss-as-parent.
> This decision has effectively crippled usage of Maven Dependency Resolver, which wasn't used in CR1-date based testsuite, so the change passed silently. 
> If user wants to use the ShrinkWrap Dependency Resolver in the AS7 testsuite, he won't get the required transitive dependencies, such as wagon or aether, so the resolver is unusable.
> According to disscussion with Vladimir, it would help "to flatten" dependency tree for ShrinkWrap dependency Resolver, however, that's only the part of the solution, the restrictions posed in AS7 parent must be relaxed afterwards.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:17:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1301) Update OSGi to be
 compatible with JBoss Modules 1.1 series
In-Reply-To: <970188.57854.1310766324068.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <991388808.84627.1311765443717.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler reassigned AS7-1301:
-----------------------------------

    Assignee: David Lloyd  (was: Thomas Diesler)


I have a framework update ready in

https://github.com/tdiesler/jbosgi-framework/tree/osgi483

It relies on a minor change in modules that allows system paths to be optionally defined

https://github.com/jbossas/jboss-modules/pull/5

> Update OSGi to be compatible with JBoss Modules 1.1 series
> ----------------------------------------------------------
>
>                 Key: AS7-1301
>                 URL: https://issues.jboss.org/browse/AS7-1301
>             Project: Application Server 7
>          Issue Type: Task
>          Components: OSGi
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 7.1.0.Alpha1
>
>
> JBoss Modules 1.1 has two significant changes.  First, jaxpmodule is eliminated.  Second, the system module is no more - instead there's a dependency type for the system class loader.
> I currently have an updated AS in my http://github.com/dmlloyd/jboss-as/tree/upgrades branch.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:23:25 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:23:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1411) Tattletale errors in
	OSGi layer
In-Reply-To: <1549913440.84172.1311756743860.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1837819366.84716.1311765805407.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler reassigned AS7-1411:
-----------------------------------

    Assignee: Jesper Pedersen  (was: Thomas Diesler)


Could you give a little more information than this? What are the errors? Do you have a branch I can look at?

> Tattletale errors in OSGi layer
> -------------------------------
>
>                 Key: AS7-1411
>                 URL: https://issues.jboss.org/browse/AS7-1411
>             Project: Application Server 7
>          Issue Type: Task
>          Components: OSGi
>            Reporter: David Bosschaert
>            Assignee: Jesper Pedersen
>
> From Jesper Pedersen:
> There are a lot of ERRORs from the OSGi layer...
> To run: java -jar tattletale.jar jboss-7.0.0.Final/ as7 
> You can also observer the tattletale report on Jenkins here: https://hudson.mw.lab.eng.bos.redhat.com/hudson/view/JBoss%20AS/job/JBoss-AS-7.0.x-TattleTale/

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:25:23 2011
From: jira-events at lists.jboss.org (Karel Piwko (JIRA))
Date: Wed, 27 Jul 2011 07:25:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBBUILD-689) Add JGit
 repository to Maven repository
In-Reply-To: <1031274966.79166.1311588563657.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2016666619.84720.1311765923750.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBBUILD-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616937#comment-12616937 ] 

Karel Piwko commented on JBBUILD-689:
-------------------------------------

{code}
<groupId>org.eclipse.jgit</groupId>
{code}

List of all artifacts is here http://www.eclipse.org/jgit/download/. 

According to what I have downloaded so far the checksums are valid.

{code}
[kpiwko at kapy-ntb 1.0.0.201106090707-r]$ sha1sum org.eclipse.jgit-1.0.0.201106090707-r.jar
34e70691382d67ee5c84ef207fb8d3784594ba2c  org.eclipse.jgit-1.0.0.201106090707-r.jar
[kpiwko at kapy-ntb 1.0.0.201106090707-r]$ cat org.eclipse.jgit-1.0.0.201106090707-r.jar.sha1 
34e70691382d67ee5c84ef207fb8d3784594ba2c[kpiwko at kapy-ntb 1.0.0.201106090707-r]$ 
{code}


> Add JGit repository to Maven repository
> ---------------------------------------
>
>                 Key: JBBUILD-689
>                 URL: https://issues.jboss.org/browse/JBBUILD-689
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: Artifact Repositories
>            Reporter: Karel Piwko
>            Assignee: Paul Gier
>             Fix For: Build Support 2011
>
>
> Please add repository [1] to our Nexus instance. I'm using
> this dependency in Arquillian OpenShift Express container and
> having a extra repository defined in pom is not a way how we should do
> it.
> {code}
> <repositories>
>     <repository>
>         <id>jgit-repository</id>
>         <url>http://download.eclipse.org/jgit/maven</url>
>     </repository>
> </repositories>
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:47:24 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:47:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1152) service-ref in
 ejb-jar.xml is ignored
In-Reply-To: <23130101.1197023272036.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2003178115.84840.1311767244912.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/EJBTHREE-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved EJBTHREE-1152.
--------------------------------------

    Resolution: Out of Date


Out of Date

> service-ref in ejb-jar.xml is ignored
> -------------------------------------
>
>                 Key: EJBTHREE-1152
>                 URL: https://issues.jboss.org/browse/EJBTHREE-1152
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>            Assignee: Carlo de Wolf
>             Fix For: Unscheduled
>
>
> [tdiesler at tddell trunk]$ ant -Dtest=org.jboss.test.ws.jaxws.samples.serviceref.ServiceRefEJBTestCase one-test 
> one-test:
>     [junit] Running org.jboss.test.ws.jaxws.samples.serviceref.ServiceRefEJBTestCase
>     [junit] Tests run: 3, Failures: 0, Errors: 1, Time elapsed: 8.761 sec
>     [junit] Test org.jboss.test.ws.jaxws.samples.serviceref.ServiceRefEJBTestCase FAILED
> Caused by: javax.naming.NameNotFoundException: service1 not bound
>         at org.jnp.server.NamingServer.getBinding(NamingServer.java:542)
>         at org.jnp.server.NamingServer.getBinding(NamingServer.java:550)
>         at org.jnp.server.NamingServer.getObject(NamingServer.java:556)
>         at org.jnp.server.NamingServer.lookup(NamingServer.java:296)
>         at org.jnp.server.NamingServer.lookup(NamingServer.java:270)
>         at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:669)
>         at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:776)
>         at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:629)
>         at javax.naming.InitialContext.lookup(InitialContext.java:351)
>         at org.jboss.test.ws.jaxws.samples.serviceref.EJBClient.echo(EJBClient.java:52)
> <ejb-jar version="3.0"
>          xmlns="http://java.sun.com/xml/ns/javaee"
>          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>          xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd">
>   <enterprise-beans>
>     <session>
>       <ejb-name>EJBClient</ejb-name>
>       <remote>org.jboss.test.ws.jaxws.samples.serviceref.EJBRemote</remote>
>       <ejb-class>org.jboss.test.ws.jaxws.samples.serviceref.EJBClient</ejb-class>
>       <session-type>Stateless</session-type>
>       <transaction-type>Container</transaction-type>
>       
>       <service-ref>
>         <service-ref-name>service1</service-ref-name>
>         <service-interface>javax.xml.ws.Service</service-interface>
>         <wsdl-file>META-INF/wsdl/TestEndpoint.wsdl</wsdl-file>
>         <service-qname xmlns:ns1="http://serviceref.samples.jaxws.ws.test.jboss.org/">ns1:TestEndpointService</service-qname>
>       </service-ref>
>     
>       <service-ref>
>         <service-ref-name>service2</service-ref-name>
>         <service-interface>org.jboss.test.ws.jaxws.samples.serviceref.TestEndpointService</service-interface>
>         <wsdl-file>META-INF/wsdl/TestEndpoint.wsdl</wsdl-file>
>         <service-qname xmlns:ns1="http://serviceref.samples.jaxws.ws.test.jboss.org/">ns1:TestEndpointService</service-qname>
>         <port-component-ref>
>           <service-endpoint-interface>org.jboss.test.ws.jaxws.samples.serviceref.TestEndpoint</service-endpoint-interface>
>           <enable-mtom>true</enable-mtom>
>         </port-component-ref>
>       </service-ref>
>       
>     </session>
>   </enterprise-beans>
>   
> </ejb-jar>

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:47:25 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:47:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCL-168) Add support for
 getModule() on Requirement/Capability
In-Reply-To: <866465952.7008.1276771911407.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <745857780.84846.1311767245340.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBCL-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved JBCL-168.
---------------------------------

    Resolution: Out of Date


Out of Date

> Add support for getModule() on Requirement/Capability
> -----------------------------------------------------
>
>                 Key: JBCL-168
>                 URL: https://issues.jboss.org/browse/JBCL-168
>             Project: JBoss ClassLoader
>          Issue Type: Task
>            Reporter: Thomas Diesler
>            Assignee: Ales Justin
>
> An alterante would be adding a mixin index to Capability so that you can get the Module, with AbstractCapability implementing it instead for this.
> e.g.
> public interface CapabilityModule
> {
>     Module.getModule();
> }
> if (capability instanceof CapabilityModule)
> {
>     resolved = ((CapabilityModule) capability).getModule().isResovled():
> }

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:47:25 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:47:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-122) Links should be
	recognized
In-Reply-To: <8232553.1158305854518.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <482994295.84849.1311767245608.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBFORUMS-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved JBFORUMS-122.
-------------------------------------

    Resolution: Out of Date


Out of Date

> Links should be recognized
> --------------------------
>
>                 Key: JBFORUMS-122
>                 URL: https://issues.jboss.org/browse/JBFORUMS-122
>             Project: JBoss Forums
>          Issue Type: Feature Request
>          Components: Forum Enhancements
>            Reporter: Thomas Diesler
>            Assignee: Ryszard Kozmik
>             Fix For: 1.3.0 Alpha
>
>
> Instead of 
> [url]http://jira.jboss.com/jira/secure/CreateIssue.jspa[/url]
> I like to simply use
> http://jira.jboss.com/jira/secure/CreateIssue.jspa
> There are a lot of user provided links that I cannot click on.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:47:25 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:47:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-7910) jmx-console does
 not display CompositeData properly
In-Reply-To: <1406243684.1270729538674.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <905892235.84852.1311767245827.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBAS-7910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved JBAS-7910.
----------------------------------

    Resolution: Out of Date


Out of Date

> jmx-console does not display CompositeData properly
> ---------------------------------------------------
>
>                 Key: JBAS-7910
>                 URL: https://issues.jboss.org/browse/JBAS-7910
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>
> The JMX spec defines with Open MBean generic data transfer types that are self describing. The jmx-console should display these open types properly instead of just showing their string representation.
> http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=osgi.core%3Atype%3DbundleState%2Cversion%3D1.5
> listBundles
> javax.management.openmbean.TabularDataSupport(tabularType=javax.management.openmbean.TabularType(name=BUNDLES,rowType=javax.management.openmbean.CompositeType(name=BUNDLE,items=((itemName=ExportedPackages,itemType=javax.management.openmbean.ArrayType(name=[Ljava.lang.String;,dimension=1,elementType=javax.management.openmbean.SimpleType(name=java.lang.String),primitiveArray=false)),(itemName=Fragment,itemType=javax.management.openmbean.SimpleType(name=java.lang.Boolean)),(itemName=Fragments,itemType=javax.management.openmbean.ArrayType(name=[Ljava.lang.Long;,dimension=1,elementType=javax.management.openmbean.SimpleType(name=java.lang.Long),primitiveArray=false)),(itemName=Headers,itemType=javax.management.openmbean.TabularType(name=HEADERS,rowType=javax.management.openmbean.CompositeType(name=HEADER,items=((itemName=Key,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=Value,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)))),indexNames=(Key))),(itemName=Hosts,itemType=javax.management.openmbean.ArrayType(name=[Ljava.lang.Long;,dimension=1,elementType=javax.management.openmbean.SimpleType(name=java.lang.Long),primitiveArray=false)),(itemName=Identifier,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),(itemName=ImportedPackages,itemType=javax.management.openmbean.ArrayType(name=[Ljava.lang.String;,dimension=1,elementType=javax.management.openmbean.SimpleType(name=java.lang.String),primitiveArray=false)),(itemName=LastModified,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),(itemName=Location,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=PersistentlyStarted,itemType=javax.management.openmbean.SimpleType(name=java.lang.Boolean)),(itemName=RegisteredServices,itemType=javax.management.openmbean.ArrayType(name=[Ljava.lang.Long;,dimension=1,elementType=javax.management.openmbean.SimpleType(name=java.lang.Long),primitiveArray=false)),(itemName=RemovalPending,itemType=javax.management.openmbean.SimpleType(name=java.lang.Boolean)),(itemName=Required,itemType=javax.management.openmbean.SimpleType(name=java.lang.Boolean)),
> ...

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Wed Jul 27 07:47:26 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:47:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBXB-208) Provide an
 annotation based tutorial for JBossXB
In-Reply-To: <1932767477.1246435651400.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <972282279.84857.1311767246247.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBXB-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved JBXB-208.
---------------------------------

    Resolution: Out of Date


Out of Date

> Provide an annotation based tutorial for JBossXB
> ------------------------------------------------
>
>                 Key: JBXB-208
>                 URL: https://issues.jboss.org/browse/JBXB-208
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>
> You've specified the namespace using JBossXmlSchema annotation. Which is correct. You should still add namespace element to the XmlRootElement annotation, which is a bit confusing having JBossXmlSchema. You don't have to do that XmlElement annotations.
> Unfortunately, we don't have JAXB tutorial for JBossXB. But you can find one for JAXB on Sun's web-site and use javadoc. For examples you can see tests in XB http://anonsvn.jboss.org/repos/common/jbossxb/trunk/src/test/java/org/jboss/test/xb/builder/object/

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:47:26 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:47:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-85) Docu on the purpose
	of BPEL
Message-ID: <1781198267.84860.1311767246506.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/BPEL-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved BPEL-85.
--------------------------------

    Resolution: Out of Date


Out of Date

> Docu on the purpose of BPEL
> ---------------------------
>
>                 Key: BPEL-85
>                 URL: https://issues.jboss.org/browse/BPEL-85
>             Project: jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documents
>    Affects Versions: jBPM BPEL 1.0 alpha 4
>            Reporter: Thomas Diesler
>            Assignee: Alejandro Guizar
>             Fix For: jBPM BPEL 1.2 GA
>
>
> Please expand the user documentation to a section about the purpose of BPEL. It should show a not so trivial use case that illustrates (with pictures) why I should care about BPEL

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:47:26 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:47:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-214) Add listener
 hooks for deployment processing
In-Reply-To: <598562079.1253109263946.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1187646643.84866.1311767246696.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBDEPLOY-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved JBDEPLOY-214.
-------------------------------------

    Resolution: Out of Date


Out of Date

> Add listener hooks for deployment processing
> --------------------------------------------
>
>                 Key: JBDEPLOY-214
>                 URL: https://issues.jboss.org/browse/JBDEPLOY-214
>             Project: JBoss Deployers
>          Issue Type: Feature Request
>            Reporter: Thomas Diesler
>
> Currently JBossOSGi wraps the Deployers to do some post processing
>    public void process(List<DeploymentContext> deploy, List<DeploymentContext> undeploy)
>    {
>       // Delegate to the original deployers
>       deployers.process(deploy, undeploy);
>       // OSGi bundles resolve phase 
>       afterDeployersProcess(deploy, undeploy);
>    }
> Perhaps this should be supported by the Deployers natively

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:47:27 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:47:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-225) Create
 ErrorHandler to DeploymentControllerContext
In-Reply-To: <704750684.1258711529741.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <600816002.84874.1311767247162.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBDEPLOY-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved JBDEPLOY-225.
-------------------------------------

    Resolution: Out of Date


Out of Date

> Create ErrorHandler to DeploymentControllerContext 
> ---------------------------------------------------
>
>                 Key: JBDEPLOY-225
>                 URL: https://issues.jboss.org/browse/JBDEPLOY-225
>             Project: JBoss Deployers
>          Issue Type: Feature Request
>            Reporter: Thomas Diesler
>            Assignee: Ales Justin
>
> The MC Framework incorrectly uninstalls the bundle if there is a failure in bundle.start()
> The controller context reached its required stage DESCRIBED after bundle install. A subsequent call to bundle.start() is supposed to transition to stages CLASSLOADER and then INSTALLED, which corresponds to the Bundle states RESOLVED and ACTIVE respectively.
> If the transition to INSTALLED fails, the controller context gets undeployed, which causes the bundle to transition to UNINSTALLED.
> The desired behaviour is:
> * on fail to resolve: remain in state INSTALLED
> * on fail to start: remain in state RESOLVED
> The proposed solution is to add an ErrorHandler to the DeploymentControllerContext
> if it is an OSGi deployment

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:47:27 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:47:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCL-140) Comprehensive
 classloading framework documentation
In-Reply-To: <453402775.1264145419700.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1155907715.84879.1311767247614.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBCL-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved JBCL-140.
---------------------------------

    Resolution: Out of Date


Out of Date

> Comprehensive classloading framework documentation
> --------------------------------------------------
>
>                 Key: JBCL-140
>                 URL: https://issues.jboss.org/browse/JBCL-140
>             Project: JBoss ClassLoader
>          Issue Type: Task
>          Components: General
>            Reporter: Thomas Diesler
>
> Please provide comprehensive documentation for the classloading framework. Improved javadoc is also covered by this issue.
> For trunk it is possible to publish the javadoc in the hudson QA environment.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:47:27 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:47:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBXB-210) Property order
 cannot be defined on super type
In-Reply-To: <1151868256.1246624731398.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <606188181.84882.1311767247891.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBXB-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved JBXB-210.
---------------------------------

    Resolution: Out of Date


Out of Date

> Property order cannot be defined on super type
> ----------------------------------------------
>
>                 Key: JBXB-210
>                 URL: https://issues.jboss.org/browse/JBXB-210
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Thomas Diesler
>
> Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Property order is not specified for type org.jboss.osgi.blueprint.parser.xb.TReference bound to a sequence. Property order can be specified using @XmlType.propOrder or @XmlAccessorOrder. List of properties: referenceListeners dependsOn initialization componentName description any interfaceNames otherAttributes timeout filter availability
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.assertPropOrderNotRequired(JBossXBNoSchemaBuilder.java:1278)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateType(JBossXBNoSchemaBuilder.java:1071)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:779)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateBean(JBossXBNoSchemaBuilder.java:767)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.generateTypeBinding(JBossXBNoSchemaBuilder.java:523)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.resolveTypeBinding(JBossXBNoSchemaBuilder.java:482)
> 	at org.jboss.xb.builder.JBossXBNoSchemaBuilder.bindProperty(JBossXBNoSchemaBuilder.java:1684)
> @XmlType(name = "Treference", namespace = BlueprintContext.XMLNS_BLUEPRINT)
> public class TReference extends TServiceReference
> @XmlType(name = "TserviceReference", namespace = BlueprintContext.XMLNS_BLUEPRINT, propOrder = { "description" })
> public class TServiceReference extends TComponent

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:47:28 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:47:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCL-169) Support attribute
 matching from OSGi
In-Reply-To: <474007796.7031.1276772806508.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1205945719.84887.1311767248362.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBCL-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved JBCL-169.
---------------------------------

    Resolution: Out of Date


Out of Date

> Support attribute matching from OSGi
> ------------------------------------
>
>                 Key: JBCL-169
>                 URL: https://issues.jboss.org/browse/JBCL-169
>             Project: JBoss ClassLoader
>          Issue Type: Task
>            Reporter: Thomas Diesler
>            Assignee: Ales Justin
>
> And another thing that needs to happen is to bubble the attribute matching from OSGi to jboss classloading.
> The only reason I originally created OSGi*Capability/Requirement was to implement the attribute matching without modifying
> jboss classloading so it could be used in older versions of jboss5. That restriction was broken by other changes a long time ago.
> We might never have got into this horrible situation if I hadn't done that.
> You should be able to do things like the following in jboss-classloading.xml:
> <capabilities>
>    <package name="foo" attributes="a=b,c=d"/>
> </capabilities>
> <requirements>
>    <package name="bar" match-attributes="(vendor=acme)"/>
> </requirements>

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:47:28 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:47:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1282) Add jaxws test
	coverage
In-Reply-To: <275758.1208264754993.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <723596043.84890.1311767248679.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/EJBTHREE-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved EJBTHREE-1282.
--------------------------------------

    Resolution: Out of Date


Out of Date

> Add jaxws test coverage
> -----------------------
>
>                 Key: EJBTHREE-1282
>                 URL: https://issues.jboss.org/browse/EJBTHREE-1282
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Thomas Diesler
>            Assignee: Heiko Braun
>             Fix For: Unscheduled
>
>
> Container issues for required WS functionality

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:47:28 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:47:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBBUILD-602) Missing
	javax.jms:jms:jar:1.1
In-Reply-To: <953241368.1271939051585.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1025734527.84893.1311767248846.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBBUILD-602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved JBBUILD-602.
------------------------------------

    Resolution: Out of Date


Out of Date

> Missing javax.jms:jms:jar:1.1
> -----------------------------
>
>                 Key: JBBUILD-602
>                 URL: https://issues.jboss.org/browse/JBBUILD-602
>             Project: JBoss Build System
>          Issue Type: Bug
>          Components: Artifact Repositories
>            Reporter: Thomas Diesler
>            Assignee: Paul Gier
>             Fix For: Build Support 2011
>
>
> Missing:
> ----------
> 1) javax.jms:jms:jar:1.1
>   Try downloading the file manually from: 
>       http://java.sun.com/products/jms/docs.html
>   Then, install it using the command: 
>       mvn install:install-file -DgroupId=javax.jms -DartifactId=jms -Dversion=1.1 -Dpackaging=jar -Dfile=/path/to/file
>   Alternatively, if you host your own repository you can deploy the file there: 
>       mvn deploy:deploy-file -DgroupId=javax.jms -DartifactId=jms -Dversion=1.1 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
>   Path to dependency: 
>   	1) org.jboss.osgi.framework:jboss-osgi-framework:jar:1.0.0.Alpha5-SNAPSHOT
>   	2) org.jboss.logging:jboss-logging-log4j:jar:2.2.0.CR1
>   	3) log4j:log4j:jar:1.2.15
>   	4) javax.jms:jms:jar:1.1

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:47:28 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:47:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1284) JAX-WS handler
 access to ejb3 context
In-Reply-To: <28701697.1208264762673.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <41723654.84896.1311767248956.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/EJBTHREE-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved EJBTHREE-1284.
--------------------------------------

    Resolution: Out of Date


Out of Date

> JAX-WS handler access to ejb3 context
> -------------------------------------
>
>                 Key: EJBTHREE-1284
>                 URL: https://issues.jboss.org/browse/EJBTHREE-1284
>             Project: EJB 3.0
>          Issue Type: Sub-task
>            Reporter: Thomas Diesler
>            Assignee: Heiko Braun
>
> i.e. security context

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:47:29 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBXB-202) Inconsistent
 initialization of XSImplementation
In-Reply-To: <2094113.1243250216412.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19491888.84898.1311767249110.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBXB-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved JBXB-202.
---------------------------------

    Resolution: Out of Date


Out of Date

> Inconsistent initialization of XSImplementation
> -----------------------------------------------
>
>                 Key: JBXB-202
>                 URL: https://issues.jboss.org/browse/JBXB-202
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Thomas Diesler
>
> In Util there is 
>     private static XSImplementation xsImpl;
> which gets initialized lazily  in
>    public static XSModel loadSchema(String xsdURL, SchemaBindingResolver schemaResolver)
>    {
>       if(xsImpl == null)
>       {
>          xsImpl = getXSImplementation();
>       }
> All other loadSchema method do not reuse the static property
> Also, 
>     private static XSImplementation getXSImplementation()
> relies on the thread context classloader, which is not available in an OSGi environment.
> Could you please provide an JBossXB initialization entry point that is public and does not make an assumption on the availability of the TCCL

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:47:29 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBXB-201) Cannot parse
	schema/jbxb_1_0.xsd
In-Reply-To: <14174635.1243249868397.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1696172587.84900.1311767249195.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBXB-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved JBXB-201.
---------------------------------

    Resolution: Out of Date


Out of Date

> Cannot parse schema/jbxb_1_0.xsd
> --------------------------------
>
>                 Key: JBXB-201
>                 URL: https://issues.jboss.org/browse/JBXB-201
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Thomas Diesler
>
> This code
>          String jbxbSchema = "schema/jbxb_1_0.xsd";
>          URL jbxbXSD = context.getBundle().getResource(jbxbSchema);
>          if (jbxbXSD == null)
>             throw new IllegalStateException("Cannot find: " + jbxbSchema);
>          
>          XSModel xsModel = Util.loadSchema(jbxbXSD.toExternalForm(), (SchemaBindingResolver)null);
>          if (xsModel == null)
>             throw new IllegalStateException("Cannot load schema: " + jbxbSchema);
> fails with 
> Caused by: org.jboss.xb.binding.JBossXBRuntimeException: -1:-1 94:47 src-element.3: Element 'class' has both a 'type' attribute and a 'anonymous type' child. Only one of these is allowed for an element.
> 	at org.jboss.xb.binding.sunday.unmarshalling.XsdBinderTerminatingErrorHandler.handleError(XsdBinderTerminatingErrorHandler.java:40)
> 	at org.apache.xerces.impl.xs.XMLSchemaLoader.reportDOMFatalError(Unknown Source)
> 	at org.apache.xerces.impl.xs.XSLoaderImpl.loadURI(Unknown Source)
> 	at org.jboss.xb.binding.Util.loadSchema(Util.java:367)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:47:29 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMICROCONT-451) Dependency on
 deprecated artifacts
In-Reply-To: <569444988.1273426745630.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1486835007.84903.1311767249441.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMICROCONT-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved JBMICROCONT-451.
----------------------------------------

    Resolution: Out of Date


Out of Date

> Dependency on deprecated artifacts
> ----------------------------------
>
>                 Key: JBMICROCONT-451
>                 URL: https://issues.jboss.org/browse/JBMICROCONT-451
>             Project: JBoss Microcontainer
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>            Assignee: Kabir Khan
>
> Missing:
> ----------
> 1) apache-log4j:log4j:jar:1.2.14
>   Try downloading the file manually from the project website.
>   Then, install it using the command: 
>       mvn install:install-file -DgroupId=apache-log4j -DartifactId=log4j -Dversion=1.2.14 -Dpackaging=jar -Dfile=/path/to/file
>   Alternatively, if you host your own repository you can deploy the file there: 
>       mvn deploy:deploy-file -DgroupId=apache-log4j -DartifactId=log4j -Dversion=1.2.14 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
>   Path to dependency: 
>   	1) org.jboss.kernel:jboss-kernel:jar:2.2.0-SNAPSHOT
>   	2) org.jboss.test:jboss-test:jar:1.1.1.GA
>   	3) apache-log4j:log4j:jar:1.2.14
> 2) apache-xerces:xml-apis:jar:2.9.1
>   Try downloading the file manually from the project website.
>   Then, install it using the command: 
>       mvn install:install-file -DgroupId=apache-xerces -DartifactId=xml-apis -Dversion=2.9.1 -Dpackaging=jar -Dfile=/path/to/file
>   Alternatively, if you host your own repository you can deploy the file there: 
>       mvn deploy:deploy-file -DgroupId=apache-xerces -DartifactId=xml-apis -Dversion=2.9.1 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
>   Path to dependency: 
>   	1) org.jboss.kernel:jboss-kernel:jar:2.2.0-SNAPSHOT
>   	2) org.jboss:jbossxb:jar:2.0.2.Beta6
>   	3) apache-xerces:xml-apis:jar:2.9.1

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:47:29 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-263) Invalid
 dependency on apache-log4j:log4j:jar:1.2.14
In-Reply-To: <1413576040.14248.1277368306806.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2096949609.84905.1311767249725.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBDEPLOY-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved JBDEPLOY-263.
-------------------------------------

    Resolution: Out of Date


Out of Date

> Invalid dependency on apache-log4j:log4j:jar:1.2.14
> ---------------------------------------------------
>
>                 Key: JBDEPLOY-263
>                 URL: https://issues.jboss.org/browse/JBDEPLOY-263
>             Project: JBoss Deployers
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>
> deployers/trunk does not build
> [INFO] Building JBoss Deployers Core
> ...
> [INFO] Failed to resolve artifact.
> Missing:
> ----------
> 1) apache-log4j:log4j:jar:1.2.14
>   Try downloading the file manually from the project website.
>   Then, install it using the command: 
>       mvn install:install-file -DgroupId=apache-log4j -DartifactId=log4j -Dversion=1.2.14 -Dpackaging=jar -Dfile=/path/to/file
>   Alternatively, if you host your own repository you can deploy the file there: 
>       mvn deploy:deploy-file -DgroupId=apache-log4j -DartifactId=log4j -Dversion=1.2.14 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
>   Path to dependency: 
>   	1) org.jboss.deployers:jboss-deployers-core:jar:2.2.0-SNAPSHOT
>   	2) org.jboss.test:jboss-test:jar:1.1.1.GA
>   	3) apache-log4j:log4j:jar:1.2.14
> ----------
> 1 required artifact is missing.
> for artifact: 
>   org.jboss.deployers:jboss-deployers-core:jar:2.2.0-SNAPSHOT
> from the specified remote repositories:
>   jboss-developer-repository-group (https://repository.jboss.org/nexus/content/groups/developer/)
> Perhaps this is a deprecated dependency

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:47:30 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:47:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCL-133) Add resolver
	preferences
In-Reply-To: <622133105.1260786630773.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <899755750.84914.1311767250511.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBCL-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved JBCL-133.
---------------------------------

    Resolution: Out of Date


Out of Date

> Add resolver preferences
> ------------------------
>
>                 Key: JBCL-133
>                 URL: https://issues.jboss.org/browse/JBCL-133
>             Project: JBoss ClassLoader
>          Issue Type: Sub-task
>            Reporter: Thomas Diesler
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:47:30 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:47:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCL-167) Mixin interface for
 optimized requirement resolution
In-Reply-To: <1473970583.6997.1276771007186.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1566981114.84917.1311767250588.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBCL-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved JBCL-167.
---------------------------------

    Resolution: Out of Date


Out of Date

> Mixin interface for optimized requirement resolution
> ----------------------------------------------------
>
>                 Key: JBCL-167
>                 URL: https://issues.jboss.org/browse/JBCL-167
>             Project: JBoss ClassLoader
>          Issue Type: Task
>            Reporter: Thomas Diesler
>            Assignee: Ales Justin
>
> /**
> * Mixin interface for custom resolution by a requirement
> */
> public interface CustomResolution extends Requirement
> {
>     /**
>      * Resolve the requirement
>      *
>      * @param domain the domain against which to resolve
>      * @return the resolved module or null if it is not resolved
>      */
>     Module resolves(Domain domain);
> }
> if (requirement instanceof CustomResolution)
>    return requirement.resolves(this);
> else
>    // do old code

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:47:30 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:47:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-169) Comprehensive
 deployer framework documentation
In-Reply-To: <15649811.1236164122377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1362995705.84923.1311767250846.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBDEPLOY-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved JBDEPLOY-169.
-------------------------------------

    Resolution: Out of Date


Out of Date

> Comprehensive deployer framework documentation
> ----------------------------------------------
>
>                 Key: JBDEPLOY-169
>                 URL: https://issues.jboss.org/browse/JBDEPLOY-169
>             Project: JBoss Deployers
>          Issue Type: Task
>          Components: general
>            Reporter: Thomas Diesler
>            Assignee: Ales Justin
>
> Please provide comprehensive documentation for the deployer framework. It should cover the individual types of deployers, deployment states, dependency items, modules,  etc. Improved javadoc is also covered by this issue.
> For trunk it is possible to publish the javadoc in the hudson QA environment.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:47:31 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:47:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBXB-209) Enum parsing
 requires value equal to type name
In-Reply-To: <1699476865.1246607631546.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <962137668.84928.1311767251202.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBXB-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved JBXB-209.
---------------------------------

    Resolution: Out of Date


Out of Date

> Enum parsing requires value equal to type name
> ----------------------------------------------
>
>                 Key: JBXB-209
>                 URL: https://issues.jboss.org/browse/JBXB-209
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-2.0.1.GA
>            Reporter: Thomas Diesler
>
> Caused by: java.lang.RuntimeException: Invalid value mandatory valid are [MANDATORY, OPTIONAL]
> 	at org.jboss.xb.builder.runtime.EnumValueAdapter.cast(EnumValueAdapter.java:136)
> 	at org.jboss.xb.builder.runtime.AbstractPropertyHandler.attribute(AbstractPropertyHandler.java:115)
> 	at org.jboss.xb.binding.sunday.unmarshalling.AttributesHandler.attributes(AttributesHandler.java:51)
> 	at org.jboss.xb.binding.sunday.unmarshalling.DefaultElementHandler.attributes(DefaultElementHandler.java:65)
> 	at org.jboss.xb.builder.runtime.BeanHandler.startParticle(BeanHandler.java:124)
> 	at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:630)
> 	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$DelegatingContentHandler.startElement(SaxJBossXBParser.java:401)
> 	at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
> public enum TAvailability
> {
>    MANDATORY("mandatory"), 
>    OPTIONAL("optional");
>    private final String value;
>    TAvailability(String v)
>    {
>       value = v;
>    }
>    public String value()
>    {
>       return value;
>    }
>    public static TAvailability fromValue(String v)
>    {
>       for (TAvailability c : TAvailability.values())
>       {
>          if (c.value.equals(v))
>          {
>             return c;
>          }
>       }
>       throw new IllegalArgumentException(v);
>    }
> }

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:47:31 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:47:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBDEPLOY-245) Prevent
 unexpected dependee state changes
In-Reply-To: <705497448.1267429930026.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <559059715.84926.1311767251102.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBDEPLOY-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved JBDEPLOY-245.
-------------------------------------

    Resolution: Out of Date


Out of Date

> Prevent unexpected dependee state changes
> -----------------------------------------
>
>                 Key: JBDEPLOY-245
>                 URL: https://issues.jboss.org/browse/JBDEPLOY-245
>             Project: JBoss Deployers
>          Issue Type: Feature Request
>            Reporter: Thomas Diesler
>
> B --> X
> install(X)
> install(B)
> start(B)
> B == ACTIVE
> X == RESOLVED
> uninstall(X)
> B == ACTIVE
> The MC framework unexpectedly changes the state of B to RESOLVED

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:47:31 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:47:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMICROCONT-442) Aggregate the
 respective API docs
In-Reply-To: <1566030.1242724505227.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <240546656.84933.1311767251538.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMICROCONT-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved JBMICROCONT-442.
----------------------------------------

    Resolution: Out of Date


Out of Date

> Aggregate the respective API docs
> ---------------------------------
>
>                 Key: JBMICROCONT-442
>                 URL: https://issues.jboss.org/browse/JBMICROCONT-442
>             Project: JBoss Microcontainer
>          Issue Type: Task
>            Reporter: Thomas Diesler
>             Fix For: JBossMC-2.0.x
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:47:31 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:47:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-1287) EJB3 client
	with service-ref
In-Reply-To: <16319115.1208264874636.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <276296296.84935.1311767251660.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/EJBTHREE-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved EJBTHREE-1287.
--------------------------------------

    Resolution: Out of Date


Out of Date

> EJB3 client with service-ref
> ----------------------------
>
>                 Key: EJBTHREE-1287
>                 URL: https://issues.jboss.org/browse/EJBTHREE-1287
>             Project: EJB 3.0
>          Issue Type: Sub-task
>            Reporter: Thomas Diesler
>            Assignee: Heiko Braun
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:50:23 2011
From: jira-events at lists.jboss.org (Thomas T (JIRA))
Date: Wed, 27 Jul 2011 07:50:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1158) EJB-Timer
 Implementation is missing / not integrated
In-Reply-To: <1681158427.29289.1309423703856.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1646976619.84943.1311767423775.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616991#comment-12616991 ] 

Thomas T commented on AS7-1158:
-------------------------------

Sebastian,
would you please tell me how the workaround with quartz does look like exactly?

For me this is a blocker to get my app running with AS7 without a functional TimerService .

Thx.
Thomas

> EJB-Timer Implementation is missing / not integrated
> ----------------------------------------------------
>
>                 Key: AS7-1158
>                 URL: https://issues.jboss.org/browse/AS7-1158
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 7.0.0.CR1
>            Reporter: Sebastian Jancke
>            Assignee: jaikiran pai
>              Labels: ejb3, timer
>
> EJB-Component is missing an integrated EJB-Timer-Implementation.
> Creating a time from within an EJB gives the following stacktrace:
> ...
> {code}
> Caused by: java.lang.UnsupportedOperationException: This is a temporary non-functional timerservice. No operations are allowed on it.
>         at org.jboss.as.ejb3.component.EJBComponent$NonFunctionalTimerService.<init>(EJBComponent.java:337)
>         at org.jboss.as.ejb3.component.EJBComponent$NonFunctionalTimerService.<init>(EJBComponent.java:335)
>         at org.jboss.as.ejb3.component.EJBComponent.getTimerService(EJBComponent.java:200)
>         at org.jboss.as.ejb3.component.TimerServiceBindingSource$TimerServiceManagedReference.getInstance(TimerServiceBindingSource.java:81)
>         at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptor.java:64)
> {code}
> The problem is a missing piece in the EJBComponent.java(line 198): 
> {code}
>     public TimerService getTimerService() throws IllegalStateException {
>         // TODO: Temporary, till we have a working timerservice integrated
>         return new NonFunctionalTimerService();
>     }
> {code}
> https://github.com/jbossas/jboss-as/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/component/EJBComponent.java#L198

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:53:23 2011
From: jira-events at lists.jboss.org (Sebastian Jancke (JIRA))
Date: Wed, 27 Jul 2011 07:53:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1158) EJB-Timer
 Implementation is missing / not integrated
In-Reply-To: <1681158427.29289.1309423703856.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <656033003.84948.1311767603759.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616992#comment-12616992 ] 

Sebastian Jancke commented on AS7-1158:
---------------------------------------

Create a startup-singleton EJB, and follow the Quartz-Docu to build a Quartz-Scheduler. You will need a jta-managed datasource and an unmanaged datasource (no jta) for Quartz. To integrate with the container, use a custom JobFactory for EJB/CDI-Lookup.

> EJB-Timer Implementation is missing / not integrated
> ----------------------------------------------------
>
>                 Key: AS7-1158
>                 URL: https://issues.jboss.org/browse/AS7-1158
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 7.0.0.CR1
>            Reporter: Sebastian Jancke
>            Assignee: jaikiran pai
>              Labels: ejb3, timer
>
> EJB-Component is missing an integrated EJB-Timer-Implementation.
> Creating a time from within an EJB gives the following stacktrace:
> ...
> {code}
> Caused by: java.lang.UnsupportedOperationException: This is a temporary non-functional timerservice. No operations are allowed on it.
>         at org.jboss.as.ejb3.component.EJBComponent$NonFunctionalTimerService.<init>(EJBComponent.java:337)
>         at org.jboss.as.ejb3.component.EJBComponent$NonFunctionalTimerService.<init>(EJBComponent.java:335)
>         at org.jboss.as.ejb3.component.EJBComponent.getTimerService(EJBComponent.java:200)
>         at org.jboss.as.ejb3.component.TimerServiceBindingSource$TimerServiceManagedReference.getInstance(TimerServiceBindingSource.java:81)
>         at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptor.java:64)
> {code}
> The problem is a missing piece in the EJBComponent.java(line 198): 
> {code}
>     public TimerService getTimerService() throws IllegalStateException {
>         // TODO: Temporary, till we have a working timerservice integrated
>         return new NonFunctionalTimerService();
>     }
> {code}
> https://github.com/jbossas/jboss-as/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/component/EJBComponent.java#L198

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:55:24 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:55:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1143) Should
 pre-populated modules a high start level be loaded in lower start levels?
In-Reply-To: <988874298.27603.1309352183694.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <798706548.84966.1311767724964.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616993#comment-12616993 ] 

Thomas Diesler commented on AS7-1143:
-------------------------------------

Theoretically possible. However, it is also possible that bundle at sl=x wires to a bundle at sl=x+n. The log shows that it takes <460ms to install the complete set of bundles.

> Should pre-populated modules a high start level be loaded in lower start levels?
> --------------------------------------------------------------------------------
>
>                 Key: AS7-1143
>                 URL: https://issues.jboss.org/browse/AS7-1143
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: OSGi
>    Affects Versions: 7.0.0.CR1
>            Reporter: David Bosschaert
>            Priority: Optional
>
> A number of modules are specified to be pre-loaded in the OSGi framework in the <modules> section of the osgi subsystem configuration. 
> {code}<modules>
>     <module identifier="javaee.api"/>
>     <module identifier="org.jboss.logging"/>
>     <module identifier="org.apache.aries.util"/>
>     <module identifier="org.jboss.osgi.webconsole"/>
>     <module identifier="org.osgi.compendium"/>
>     <module identifier="org.apache.felix.log" startlevel="1"/>
>     <module identifier="org.jboss.osgi.logging" startlevel="1"/>
>     <module identifier="org.apache.felix.configadmin" startlevel="1"/>
>     <module identifier="org.jboss.as.osgi.configadmin" startlevel="1"/>
>     <module identifier="org.apache.aries.jmx" startlevel="2"/>
>     <module identifier="org.apache.felix.eventadmin" startlevel="2"/>
>     <module identifier="org.apache.felix.metatype" startlevel="2"/>
>     <module identifier="org.apache.felix.webconsole" startlevel="2"/>
>     <module identifier="org.jboss.osgi.jmx" startlevel="2"/>
>     <module identifier="org.jboss.osgi.http" startlevel="2"/>
>     <module identifier="org.jboss.osgi.blueprint" startlevel="3"/>
>     <module identifier="org.jboss.osgi.webapp" startlevel="3"/>
>     <module identifier="org.jboss.osgi.xerces" startlevel="3"/>
> </modules>{code}
> Currently all modules are loaded, regardless of start level and only those that have a start level <= the current one are actually started. I wonder whether this is desirable. When a module has a startlevel specified, it clearly needs to be started and is likely not useful when not started. It would therefore make sense to me to not pre-load modules with a higher start level, but only load these once their start level is being reached. This would improve subsystem start times too...
> I.e. even when start level 1 is specified, the following output appears when the framework is started:
> {code}13:52:28,008 INFO  [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-14) Install bundle: system.bundle:0.0.0
> 13:52:28,119 INFO  [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-6) Install bundle: javaee.api:0.0.0
> 13:52:28,119 INFO  [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-10) Install bundle: org.jboss.logging:3.0.0
> 13:52:28,133 INFO  [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-11) Install bundle: jboss-as-osgi-configadmin:7.0.0.CR1
> 13:52:28,137 INFO  [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-2) Install bundle: jbosgi-webconsole:1.0.6
> 13:52:28,140 INFO  [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-12) Install bundle: jboss-osgi-logging:1.0.0
> 13:52:28,176 INFO  [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-7) Install bundle: jboss-osgi-jmx:1.0.10
> 13:52:28,204 INFO  [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-5) Install bundle: org.apache.felix.metatype:1.0.4
> 13:52:28,219 INFO  [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-1) Install bundle: org.apache.felix.configadmin:1.2.8
> 13:52:28,228 INFO  [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-6) Install bundle: org.apache.aries.util:0.3.0
> 13:52:28,229 INFO  [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-14) Install bundle: org.apache.aries.jmx:0.3.0
> 13:52:28,237 INFO  [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-11) Install bundle: org.apache.felix.log:1.0.0
> 13:52:28,240 INFO  [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-16) Install bundle: jbosgi-blueprint:1.0.2
> 13:52:28,313 INFO  [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-3) Install bundle: jbosgi-webapp:1.0.2
> 13:52:28,325 INFO  [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-8) Install bundle: org.apache.felix.eventadmin:1.2.6
> 13:52:28,333 INFO  [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-9) Install bundle: jboss-osgi-xerces:2.9.1.SP7
> 13:52:28,368 INFO  [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-13) Install bundle: org.apache.felix.webconsole:3.1.6.SP1
> 13:52:28,394 INFO  [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-15) Install bundle: jboss-osgi-http:1.0.3
> 13:52:28,460 INFO  [org.jboss.osgi.framework.internal.BundleManager] (MSC service thread 1-4) Install bundle: osgi.cmpn:4.2.0.200908310645
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 07:59:24 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 07:59:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1132) OSGi warnings at
	startup
In-Reply-To: <733408365.25390.1309275203934.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1759798931.84984.1311767964015.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved AS7-1132.
---------------------------------

    Resolution: Duplicate Issue


Duplicates AS7-1205

> OSGi warnings at startup
> ------------------------
>
>                 Key: AS7-1132
>                 URL: https://issues.jboss.org/browse/AS7-1132
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: OSGi
>    Affects Versions: 7.0.0.CR1
>            Reporter: David Bosschaert
>            Priority: Minor
>
> While starting up AS7 the following warning appear on the console. Not sure yet whether this is serious or not. Broadly speaking the OSGi subsystem does work.
> 16:27:51,972 WARN  [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-12) Unable to set the URLStreamHandlerFactory
> 16:27:51,973 WARN  [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-12) Unable to set the ContentHandlerFactory

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 08:10:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 08:10:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1154) Integration of
 EventAdmin with AS7 components
Message-ID: <409708935.85020.1311768623664.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler updated AS7-1154:
--------------------------------

    Fix Version/s:     (was: 7.1.0.Beta1)


> Integration of EventAdmin with AS7 components
> ---------------------------------------------
>
>                 Key: AS7-1154
>                 URL: https://issues.jboss.org/browse/AS7-1154
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: OSGi
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>
> Non-OSGi components should be able to publish/receive events through EventAdmin
> and vice versa of course

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 08:13:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 08:13:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-832) Deploy EJB3 beans in
	OSGi bundle
Message-ID: <1835764632.85039.1311768803771.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler updated AS7-832:
-------------------------------

    Fix Version/s:     (was: Open To Community)


> Deploy EJB3 beans in OSGi bundle
> --------------------------------
>
>                 Key: AS7-832
>                 URL: https://issues.jboss.org/browse/AS7-832
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: OSGi
>            Reporter: Thomas Diesler
>
> Allow deployment of SLSB and possibly others in OSGi bundle.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 08:23:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 08:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1412) ServerEnvironment
 accepts invalid or non-existent directory configurations
Message-ID: <1491066976.85068.1311769403990.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

ServerEnvironment accepts invalid or non-existent directory configurations
--------------------------------------------------------------------------

                 Key: AS7-1412
                 URL: https://issues.jboss.org/browse/AS7-1412
             Project: Application Server 7
          Issue Type: Bug
            Reporter: Thomas Diesler
            Assignee: Brian Stansberry


I tried changing the testsuite/pom.xml to allow tests to override certain AS7 modules, by adding a "testsuite" modules entry to the module.path.  It looks like OSGI gets confused by multiple entries in the module path.

module.path = /home/smarlow/work/as7/testsuite/compat/target/jbossas:/home/smarlow/work/as7/testsuite/compat/../../build/target/jboss-as-7.1.0.Alpha1-SNAPSHOT/modules

server.log http://pastie.org/2278519 that shows what looks like an OSGI error.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 08:23:24 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 08:23:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1412) ServerEnvironment
 accepts invalid or non-existent directory configurations
In-Reply-To: <1491066976.85068.1311769403990.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1317924974.85071.1311769404315.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616998#comment-12616998 ] 

Thomas Diesler commented on AS7-1412:
-------------------------------------

The ServerEnvironment.getModulesDir() supports a single directory only. IHMO its a bug ServerEnvironment that it allows invalid or non-existent directory configurations.


> ServerEnvironment accepts invalid or non-existent directory configurations
> --------------------------------------------------------------------------
>
>                 Key: AS7-1412
>                 URL: https://issues.jboss.org/browse/AS7-1412
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>            Assignee: Brian Stansberry
>
> I tried changing the testsuite/pom.xml to allow tests to override certain AS7 modules, by adding a "testsuite" modules entry to the module.path.  It looks like OSGI gets confused by multiple entries in the module path.
> module.path = /home/smarlow/work/as7/testsuite/compat/target/jbossas:/home/smarlow/work/as7/testsuite/compat/../../build/target/jboss-as-7.1.0.Alpha1-SNAPSHOT/modules
> server.log http://pastie.org/2278519 that shows what looks like an OSGI error.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 08:29:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 08:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1412) ServerEnvironment
 accepts invalid or non-existent directory configurations
In-Reply-To: <1491066976.85068.1311769403990.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1585089284.85128.1311769763628.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617001#comment-12617001 ] 

Thomas Diesler commented on AS7-1412:
-------------------------------------

Please also consider adding ServerEnvironment.getBundlesDir()

> ServerEnvironment accepts invalid or non-existent directory configurations
> --------------------------------------------------------------------------
>
>                 Key: AS7-1412
>                 URL: https://issues.jboss.org/browse/AS7-1412
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>            Assignee: Brian Stansberry
>
> I tried changing the testsuite/pom.xml to allow tests to override certain AS7 modules, by adding a "testsuite" modules entry to the module.path.  It looks like OSGI gets confused by multiple entries in the module path.
> module.path = /home/smarlow/work/as7/testsuite/compat/target/jbossas:/home/smarlow/work/as7/testsuite/compat/../../build/target/jboss-as-7.1.0.Alpha1-SNAPSHOT/modules
> server.log http://pastie.org/2278519 that shows what looks like an OSGI error.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 08:31:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 27 Jul 2011 08:31:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1411) Tattletale errors in
	OSGi layer
In-Reply-To: <1549913440.84172.1311756743860.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <508456220.85133.1311769883728.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen reassigned AS7-1411:
------------------------------------

    Assignee: Thomas Diesler  (was: Jesper Pedersen)


F.ex. https://hudson.mw.lab.eng.bos.redhat.com/hudson/view/JBoss%20AS/job/JBoss-AS-7.0.x-TattleTale/ws/output-jbossas7/circulardependency/index.html shows there are circular dependencies between the JBoss OSGi artifacts and there are classes that are in multiple artifacts (https://hudson.mw.lab.eng.bos.redhat.com/hudson/view/JBoss%20AS/job/JBoss-AS-7.0.x-TattleTale/ws/output-jbossas7/multiplejars/index.html). Just go through each report and fix any OSGi stuff you find

> Tattletale errors in OSGi layer
> -------------------------------
>
>                 Key: AS7-1411
>                 URL: https://issues.jboss.org/browse/AS7-1411
>             Project: Application Server 7
>          Issue Type: Task
>          Components: OSGi
>            Reporter: David Bosschaert
>            Assignee: Thomas Diesler
>
> From Jesper Pedersen:
> There are a lot of ERRORs from the OSGi layer...
> To run: java -jar tattletale.jar jboss-7.0.0.Final/ as7 
> You can also observer the tattletale report on Jenkins here: https://hudson.mw.lab.eng.bos.redhat.com/hudson/view/JBoss%20AS/job/JBoss-AS-7.0.x-TattleTale/

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 08:33:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 27 Jul 2011 08:33:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1381) Make RA config
 properties sub resources
In-Reply-To: <796812033.76172.1311338604471.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <426421365.85139.1311770003755.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617003#comment-12617003 ] 

Jesper Pedersen commented on AS7-1381:
--------------------------------------

You should be able to modify the properties, but it'll require a restart for them to take effect. So "system properties" is a good example of the same

> Make RA config properties sub resources
> ---------------------------------------
>
>                 Key: AS7-1381
>                 URL: https://issues.jboss.org/browse/AS7-1381
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.CR1
>
>
> Take a look how system properties are represented. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 08:35:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 08:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1357) JSR-88 support
In-Reply-To: <623692364.70100.1311176723878.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2024115336.85156.1311770123774.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler reassigned AS7-1357:
-----------------------------------

    Assignee: Thomas Diesler


> JSR-88 support
> --------------
>
>                 Key: AS7-1357
>                 URL: https://issues.jboss.org/browse/AS7-1357
>             Project: Application Server 7
>          Issue Type: Task
>            Reporter: Brian Stansberry
>            Assignee: Thomas Diesler
>            Priority: Blocker
>             Fix For: 7.1.0.CR1
>
>
> Required for EE full profile certification.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 08:35:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 08:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1357) JavaEE Application
 Deployment (JSR-88) support
In-Reply-To: <623692364.70100.1311176723878.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1623369649.85159.1311770123866.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler updated AS7-1357:
--------------------------------

          Summary: JavaEE Application Deployment (JSR-88) support  (was: JSR-88 support)
    Fix Version/s: 7.1.0.CR1


> JavaEE Application Deployment (JSR-88) support
> ----------------------------------------------
>
>                 Key: AS7-1357
>                 URL: https://issues.jboss.org/browse/AS7-1357
>             Project: Application Server 7
>          Issue Type: Task
>            Reporter: Brian Stansberry
>            Assignee: Thomas Diesler
>            Priority: Blocker
>             Fix For: 7.1.0.CR1
>
>
> Required for EE full profile certification.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 08:35:24 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 08:35:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1357) JavaEE Application
 Deployment (JSR-88) support
In-Reply-To: <623692364.70100.1311176723878.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1037188289.85172.1311770124353.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler updated AS7-1357:
--------------------------------

    Issue Type: Feature Request  (was: Task)
      Priority: Major  (was: Blocker)


> JavaEE Application Deployment (JSR-88) support
> ----------------------------------------------
>
>                 Key: AS7-1357
>                 URL: https://issues.jboss.org/browse/AS7-1357
>             Project: Application Server 7
>          Issue Type: Feature Request
>            Reporter: Brian Stansberry
>            Assignee: Thomas Diesler
>             Fix For: 7.1.0.CR1
>
>
> Required for EE full profile certification.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 08:47:24 2011
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 27 Jul 2011 08:47:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3156) Singe HTML
 documentation (of Drools Expert) is broken from chapter 5 's first SVG
 image (in section railroad diagrams) onwards on firefox 5 beta 1
In-Reply-To: <1264800918.84180.1311756923624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1989966181.85227.1311770844089.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617009#comment-12617009 ] 

Geoffrey De Smet commented on JBRULES-3156:
-------------------------------------------

The SVG problems aren't easily fixable, so I am converting them to png

{code}
sudo apt-get install imagemagick
for i in `ls *.svg`;do convert -antialias $i ${i%.*}.png; done
{code}

> Singe HTML documentation (of Drools Expert) is broken from chapter 5 's first SVG image (in section railroad diagrams) onwards on firefox 5 beta 1
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3156
>                 URL: https://issues.jboss.org/browse/JBRULES-3156
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Critical
>             Fix For: 5.2.1.Final
>
>
> "Having a look at it with the html-tidy plugin from firefox there are several </span> tags which are too many and more likely the object tags are not closed correctly (you use xhtml so you need to close then with </object> the empty tag structure <object/> is invalid in xhtml)."

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 08:47:24 2011
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 27 Jul 2011 08:47:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (JBRULES-3156)
 Singe HTML documentation (of Drools Expert) is broken from chapter 5 's
 first SVG image (in section railroad diagrams) onwards on firefox 5 beta 1
In-Reply-To: <1264800918.84180.1311756923624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <959715685.85230.1311770844196.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617009#comment-12617009 ] 

Geoffrey De Smet edited comment on JBRULES-3156 at 7/27/11 8:47 AM:
--------------------------------------------------------------------

The SVG problems aren't easily fixable, so I am converting them to png

{code}
sudo apt-get install imagemagick
for i in `ls *.svg`;do convert -antialias $i ${i%.*}.png; done
{code}

Real issue is here: JDOCBOOKSTYLE-29

      was (Author: ge0ffrey):
    The SVG problems aren't easily fixable, so I am converting them to png

{code}
sudo apt-get install imagemagick
for i in `ls *.svg`;do convert -antialias $i ${i%.*}.png; done
{code}
  
> Singe HTML documentation (of Drools Expert) is broken from chapter 5 's first SVG image (in section railroad diagrams) onwards on firefox 5 beta 1
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3156
>                 URL: https://issues.jboss.org/browse/JBRULES-3156
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Critical
>             Fix For: 5.2.1.Final
>
>
> "Having a look at it with the html-tidy plugin from firefox there are several </span> tags which are too many and more likely the object tags are not closed correctly (you use xhtml so you need to close then with </object> the empty tag structure <object/> is invalid in xhtml)."

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 08:51:23 2011
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 27 Jul 2011 08:51:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-3156) Singe HTML
 documentation (of Drools Expert) is broken from chapter 5 's first SVG
 image (in section railroad diagrams) onwards on firefox 5 beta 1
In-Reply-To: <1264800918.84180.1311756923624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <626729565.85242.1311771083684.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBRULES-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet resolved JBRULES-3156.
---------------------------------------

    Resolution: Done


Fixed by workaround. Real issue raised at pressgang-tools.

> Singe HTML documentation (of Drools Expert) is broken from chapter 5 's first SVG image (in section railroad diagrams) onwards on firefox 5 beta 1
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3156
>                 URL: https://issues.jboss.org/browse/JBRULES-3156
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Critical
>             Fix For: 5.2.1.Final
>
>
> "Having a look at it with the html-tidy plugin from firefox there are several </span> tags which are too many and more likely the object tags are not closed correctly (you use xhtml so you need to close then with </object> the empty tag structure <object/> is invalid in xhtml)."

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 09:16:24 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Wed, 27 Jul 2011 09:16:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1413)
 :read-resource-description does not match :read-resource output for
 /profile=default/subsystem=web
Message-ID: <233866808.85364.1311772584413.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

:read-resource-description does not match :read-resource output for /profile=default/subsystem=web
--------------------------------------------------------------------------------------------------

                 Key: AS7-1413
                 URL: https://issues.jboss.org/browse/AS7-1413
             Project: Application Server 7
          Issue Type: Bug
          Components: Web
    Affects Versions: 7.0.0.Final
            Reporter: Heiko Rupp
            Assignee: Remy Maucherat


:read-resource gives
    "result" => {
        "configuration" => {
            "static-resources" => {
...
            },
            "jsp-configuration" => {

While :read-resource-description has no notion of "jsp-configuration" and lists everything below "static-resources"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 09:24:24 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Wed, 27 Jul 2011 09:24:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1414) Almost all
 configuration attributes for /profile=default/subsystem=web are read-only
Message-ID: <968270848.85397.1311773064131.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Almost all configuration attributes for /profile=default/subsystem=web are read-only
------------------------------------------------------------------------------------

                 Key: AS7-1414
                 URL: https://issues.jboss.org/browse/AS7-1414
             Project: Application Server 7
          Issue Type: Bug
          Components: Web
            Reporter: Heiko Rupp
            Assignee: Remy Maucherat


If you look at the resource-description for /subsystem=web, all attributes are read-only.
The administrator can not switch on webdav or disable JSP via the API

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 09:28:23 2011
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 27 Jul 2011 09:28:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBBUILD-690) The JBoss parent
 pom should be dual licenced under LGPL and ASL (not just LGPL)
Message-ID: <1004038312.85412.1311773303679.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

The JBoss parent pom should be dual licenced under LGPL and ASL (not just LGPL)
-------------------------------------------------------------------------------

                 Key: JBBUILD-690
                 URL: https://issues.jboss.org/browse/JBBUILD-690
             Project: JBoss Build System
          Issue Type: Bug
          Components: JBoss Parent POM
    Affects Versions: JBoss Parent POM - 6
            Reporter: Geoffrey De Smet
            Assignee: Paul Gier
             Fix For: JBoss Parent POM - 6


Drools and jBPM are ASL licensed and therefor can't really depend on LGPL licensed software :(
That includes the parent poms, so the jboss-parent can't be only LGPL licensed.

Option 1: Add the ASL license to make it dual licensed under LGPL and ASL:

{code}
    <license>
      <name>The Apache Software License, Version 2.0</name>
      <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url>
      <distribution>repo</distribution>
    </license>
{code}

Note: a pom that inherits from the jboss-parent pom and specifies a license, only has it's own license (try yourself with "mvn help:effective-pom".

Option 2: Only use an ASL license, because LGPL can use ASL (and not the other way around).

Option 3: Only use a BSD license, because LGPL and ASL can use that.
Note: you need to specify a license so <distribution>repo</distribution> can be set.


Seperate issue: add <distribution>repo</distribution> to whichever licence it uses.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 09:40:23 2011
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 27 Jul 2011 09:40:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2908) Build: Our
 parent pom must extend jboss parent pom and do not replicate anything in
 there
In-Reply-To: <924129072.213.1298557325876.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1173604769.85440.1311774023679.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617028#comment-12617028 ] 

Geoffrey De Smet commented on JBRULES-2908:
-------------------------------------------

The JBoss parent pom is littered with profiles. Not sure if we want to use that, as profiles make stuff complicated.
We got 3 profiles: default, full (= build slow stuff too), soa (= enterprise product)

> Build: Our parent pom must extend jboss parent pom and do not replicate anything in there
> -----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2908
>                 URL: https://issues.jboss.org/browse/JBRULES-2908
>             Project: Drools
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Minor
>
>  <parent>
>     <groupId>org.jboss</groupId>
>     <artifactId>jboss-parent</artifactId>
>     <version>5</version>
>   </parent>
> More info in http://community.jboss.org/wiki/MavenDeployingaSnapshot

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 09:42:23 2011
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 27 Jul 2011 09:42:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2908) Build: Our
 parent pom must extend jboss parent pom and do not replicate anything in
 there
In-Reply-To: <924129072.213.1298557325876.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <637655643.85443.1311774143617.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617029#comment-12617029 ] 

Geoffrey De Smet commented on JBRULES-2908:
-------------------------------------------

Here's the jboss parent pom:
https://github.com/jboss/jboss-parent-pom/blob/master/pom.xml

> Build: Our parent pom must extend jboss parent pom and do not replicate anything in there
> -----------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2908
>                 URL: https://issues.jboss.org/browse/JBRULES-2908
>             Project: Drools
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Minor
>
>  <parent>
>     <groupId>org.jboss</groupId>
>     <artifactId>jboss-parent</artifactId>
>     <version>5</version>
>   </parent>
> More info in http://community.jboss.org/wiki/MavenDeployingaSnapshot

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 09:44:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 27 Jul 2011 09:44:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1301) Update OSGi to be
 compatible with JBoss Modules 1.1 series
In-Reply-To: <970188.57854.1310766324068.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1016174601.85445.1311774263650.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617030#comment-12617030 ] 

David Lloyd commented on AS7-1301:
----------------------------------

The client won't normally want to do this as it incurs an expensive computation at boot.  What is the use case here?  Normally in AS you'd simply add a dependency on javax.api, and maybe sun.jdk and org.jboss.modules.

> Update OSGi to be compatible with JBoss Modules 1.1 series
> ----------------------------------------------------------
>
>                 Key: AS7-1301
>                 URL: https://issues.jboss.org/browse/AS7-1301
>             Project: Application Server 7
>          Issue Type: Task
>          Components: OSGi
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 7.1.0.Alpha1
>
>
> JBoss Modules 1.1 has two significant changes.  First, jaxpmodule is eliminated.  Second, the system module is no more - instead there's a dependency type for the system class loader.
> I currently have an updated AS in my http://github.com/dmlloyd/jboss-as/tree/upgrades branch.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 09:48:24 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 27 Jul 2011 09:48:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1412) ServerEnvironment
 accepts invalid or non-existent directory configurations
In-Reply-To: <1491066976.85068.1311769403990.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <919671018.85478.1311774504189.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617033#comment-12617033 ] 

Scott Marlow commented on AS7-1412:
-----------------------------------

I think that ServerEnvironment.getModulesDir(), should return File[].  This would be more like ServerEnvironment.getJavaExtDirs().

> ServerEnvironment accepts invalid or non-existent directory configurations
> --------------------------------------------------------------------------
>
>                 Key: AS7-1412
>                 URL: https://issues.jboss.org/browse/AS7-1412
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>            Assignee: Brian Stansberry
>
> I tried changing the testsuite/pom.xml to allow tests to override certain AS7 modules, by adding a "testsuite" modules entry to the module.path.  It looks like OSGI gets confused by multiple entries in the module path.
> module.path = /home/smarlow/work/as7/testsuite/compat/target/jbossas:/home/smarlow/work/as7/testsuite/compat/../../build/target/jboss-as-7.1.0.Alpha1-SNAPSHOT/modules
> server.log http://pastie.org/2278519 that shows what looks like an OSGI error.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 09:55:23 2011
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 27 Jul 2011 09:55:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-2591) Documentation
 contains duplicate section (one in use, one dead code)
In-Reply-To: <661955551.3127.1280155233640.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1975640857.85499.1311774923808.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBRULES-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet resolved JBRULES-2591.
---------------------------------------

         Assignee: Geoffrey De Smet  (was: Mark Proctor)
    Fix Version/s: 5.2.0.Final
                       (was: 5.3.0.Beta1)
       Resolution: Done


This was fixed some time ago, probably for 5.2.0.Final.
Wolfgang had already isolated the duplicate docs in Obsolete dirs and I removed them.

> Documentation contains duplicate section (one in use, one dead code)
> --------------------------------------------------------------------
>
>                 Key: JBRULES-2591
>                 URL: https://issues.jboss.org/browse/JBRULES-2591
>             Project: Drools
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: drools-docs-expert
>    Affects Versions: 5.1.0.CR1
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>             Fix For: 5.2.0.Final
>
>
> The duplicated dead code versions are not published.
> Find out which are duplicate dead code versions and delete them.
> For example: Section-What_is_a_Rule_Engine.xml exists twice

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 09:57:24 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 27 Jul 2011 09:57:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1301) Update OSGi to be
 compatible with JBoss Modules 1.1 series
In-Reply-To: <970188.57854.1310766324068.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1207176532.85524.1311775044282.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned AS7-1301:
--------------------------------

    Assignee: Thomas Diesler  (was: David Lloyd)


> Update OSGi to be compatible with JBoss Modules 1.1 series
> ----------------------------------------------------------
>
>                 Key: AS7-1301
>                 URL: https://issues.jboss.org/browse/AS7-1301
>             Project: Application Server 7
>          Issue Type: Task
>          Components: OSGi
>            Reporter: David Lloyd
>            Assignee: Thomas Diesler
>             Fix For: 7.1.0.Alpha1
>
>
> JBoss Modules 1.1 has two significant changes.  First, jaxpmodule is eliminated.  Second, the system module is no more - instead there's a dependency type for the system class loader.
> I currently have an updated AS in my http://github.com/dmlloyd/jboss-as/tree/upgrades branch.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 10:07:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 10:07:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1301) Update OSGi to be
 compatible with JBoss Modules 1.1 series
In-Reply-To: <970188.57854.1310766324068.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2050947985.85582.1311775643951.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617038#comment-12617038 ] 

Thomas Diesler commented on AS7-1301:
-------------------------------------

The framework supports the notion of configurable system packages that can be loaded from the system bundle. 
Every bundle must be able load these packages from the system class loader 

??The Framework must always delegate any package that starts with java. to the parent class loader.??

In our implementation we define a system dependency for every host bundle. Currently I do it like this

{code}
// Add a system dependency
SystemPackagesPlugin plugin = injectedSystemPackages.getValue();
PathFilter systemPackagesFilter = plugin.getSystemPackageFilter();
PathFilter sysImportFilter = systemPackagesFilter;
PathFilter sysExportFilter = PathFilters.acceptAll();
moduleDependencies.add(DependencySpec.createSystemDependencySpec(sysImportFilter, sysExportFilter, null));
{code}

Please note the 'null' for the system paths. I could define this set explicitly, which would require an update for every jdk version, right? Meanwhile, I think a fallback to JDKPaths.JDK is ok and we can revisit when I look at framework bootstrap performance. 

> Update OSGi to be compatible with JBoss Modules 1.1 series
> ----------------------------------------------------------
>
>                 Key: AS7-1301
>                 URL: https://issues.jboss.org/browse/AS7-1301
>             Project: Application Server 7
>          Issue Type: Task
>          Components: OSGi
>            Reporter: David Lloyd
>            Assignee: Thomas Diesler
>             Fix For: 7.1.0.Alpha1
>
>
> JBoss Modules 1.1 has two significant changes.  First, jaxpmodule is eliminated.  Second, the system module is no more - instead there's a dependency type for the system class loader.
> I currently have an updated AS in my http://github.com/dmlloyd/jboss-as/tree/upgrades branch.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 10:07:24 2011
From: jira-events at lists.jboss.org (Dennis Reed (JIRA))
Date: Wed, 27 Jul 2011 10:07:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-270) Intermittent
 failure of undeploy
In-Reply-To: <199739023.3169.1299196425630.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <202473042.85602.1311775644616.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBDEPLOY-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617040#comment-12617040 ] 

Dennis Reed commented on JBDEPLOY-270:
--------------------------------------

It's not related to JBDEPLOY-184.

The problem is that:
A) the descriptor is processed separately during deploy and undeploy
B) the processing depends on the order the components are parsed in
C) the components are sometimes parsed in a different order

C is because the data is parsed into Sets, which are not ordered.
Changing A, B, or C would fix it.  It's the combination of all 3 that causes the bug.
C just seems like the simplest one to change.

> Intermittent failure of undeploy
> --------------------------------
>
>                 Key: JBDEPLOY-270
>                 URL: https://issues.jboss.org/browse/JBDEPLOY-270
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions:  JBDEPLOY-2.0.10.GA 
>            Reporter: Dennis Reed
>         Attachments: JBDEPLOY-270-jboss-beans.xml
>
>
> When components are deployed, they are assigned names with a number appended based on the order it was processed.
> For example "jboss.deployment:id="dennis$defaultEvictionRegionConfig#1",type=Component"
> The number is assigned in (line #'s are from EAP 5.0):
>     at org.jboss.beans.metadata.plugins.AbstractBeanMetaData.setName(AbstractBeanMetaData.java:360)
>     at org.jboss.beans.metadata.plugins.NestedBeanHandler.checkForNestedBeans(NestedBeanHandler.java:77)
>     at org.jboss.beans.metadata.plugins.AbstractBeanMetaData.getBeans(AbstractBeanMetaData.java:202)
>     at org.jboss.kernel.plugins.deployment.AbstractKernelDeployment.getBeans(AbstractKernelDeployment.java:233)
>     at org.jboss.deployers.vfs.deployer.kernel.KernelDeploymentDeployer$KernelDeploymentVisitor.getBeans(KernelDeploymentDeployer.java:63)
>     at org.jboss.deployers.vfs.deployer.kernel.KernelDeploymentDeployer$KernelDeploymentVisitor.getBeans(KernelDeploymentDeployer.java:54)
>     at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryVisitor.deploy(BeanMetaDataFactoryVisitor.java:118)
> However, the beans are *not* processed in the same order every time.
> And they are processed separately during deployment and undeployment.
> This means that "myBean#1" may get deployed, but "myBean#2" is undeployed (leaving "myBean#1" still deployed).
> Subsequent deployments will fail with errors:
> 17:34:30,630 WARN  [AbstractDeploymentContext] Unable to register deployment mbean dennis$defaultEvictionRegionConfig#1
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="dennis$defaultEvictionRegionConfig#1",type=Component already registered.
> The root cause appears to be that the XML descriptor is read with jboss-xb using a Set (unordered), but then 
> this code has a dependency on the order being consistent between deploy and undeploy.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 10:07:24 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 10:07:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-1301) Update
 OSGi to be compatible with JBoss Modules 1.1 series
In-Reply-To: <970188.57854.1310766324068.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1253916352.85600.1311775644549.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617038#comment-12617038 ] 

Thomas Diesler edited comment on AS7-1301 at 7/27/11 10:06 AM:
---------------------------------------------------------------

The framework supports the notion of configurable system packages that can be loaded from the system bundle. 
Every bundle must be able load these packages from the system class loader 

??The Framework must always delegate any package that starts with java. to the parent class loader.??

In our implementation we define a system dependency for every host bundle. Currently I do it like this

{code}
// Add a system dependency
SystemPackagesPlugin plugin = injectedSystemPackages.getValue();
PathFilter systemPackagesFilter = plugin.getSystemPackageFilter();
PathFilter sysImportFilter = systemPackagesFilter;
PathFilter sysExportFilter = PathFilters.acceptAll();
moduleDependencies.add(DependencySpec.createSystemDependencySpec(sysImportFilter, sysExportFilter, null));
{code}

Note the 'null' for the system paths. I could define this set explicitly, which would require an update for every jdk version, right? Meanwhile, I think a fallback to JDKPaths.JDK is ok and we can revisit when I look at framework bootstrap performance. 

      was (Author: thomas.diesler):
    The framework supports the notion of configurable system packages that can be loaded from the system bundle. 
Every bundle must be able load these packages from the system class loader 

??The Framework must always delegate any package that starts with java. to the parent class loader.??

In our implementation we define a system dependency for every host bundle. Currently I do it like this

{code}
// Add a system dependency
SystemPackagesPlugin plugin = injectedSystemPackages.getValue();
PathFilter systemPackagesFilter = plugin.getSystemPackageFilter();
PathFilter sysImportFilter = systemPackagesFilter;
PathFilter sysExportFilter = PathFilters.acceptAll();
moduleDependencies.add(DependencySpec.createSystemDependencySpec(sysImportFilter, sysExportFilter, null));
{code}

Please note the 'null' for the system paths. I could define this set explicitly, which would require an update for every jdk version, right? Meanwhile, I think a fallback to JDKPaths.JDK is ok and we can revisit when I look at framework bootstrap performance. 
  
> Update OSGi to be compatible with JBoss Modules 1.1 series
> ----------------------------------------------------------
>
>                 Key: AS7-1301
>                 URL: https://issues.jboss.org/browse/AS7-1301
>             Project: Application Server 7
>          Issue Type: Task
>          Components: OSGi
>            Reporter: David Lloyd
>            Assignee: Thomas Diesler
>             Fix For: 7.1.0.Alpha1
>
>
> JBoss Modules 1.1 has two significant changes.  First, jaxpmodule is eliminated.  Second, the system module is no more - instead there's a dependency type for the system class loader.
> I currently have an updated AS in my http://github.com/dmlloyd/jboss-as/tree/upgrades branch.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 10:11:24 2011
From: jira-events at lists.jboss.org (Burkhard Vogel (JIRA))
Date: Wed, 27 Jul 2011 10:11:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3152) Control of
 KnowledgeAgent instances
In-Reply-To: <413611220.80127.1311607043970.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <657957305.85628.1311775884871.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-3152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617041#comment-12617041 ] 

Burkhard Vogel commented on JBRULES-3152:
-----------------------------------------

We use a singleton to manage the communication from application to the jBPM runtime. When the singleton is created it creates a KnowledgeAgent which in turn updates the KnowledgeBase if a change is made to the Guvnor. As it is a singleton we have no control over the shutdown of the KnowledgeAgent and neither
ResourceFactory.getResourceChangeScannerService().stop();
ResourceFactory.getResourceChangeNotifierService().stop();
nor
kAgent.dispose() 
is called.
Problem arises when during the development cycle the application gets redeployed - then another KnowledgeAgent is created while the before exiting does not get disposed - still they carry the same name. As we do development to the console the same applies to the jbpm-gwt-server that as well creates a KnowledgeAgent and does not dispose it. 

> Control of KnowledgeAgent instances
> -----------------------------------
>
>                 Key: JBRULES-3152
>                 URL: https://issues.jboss.org/browse/JBRULES-3152
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.2.0.Final
>            Reporter: Burkhard Vogel
>            Assignee: Mark Proctor
>
> There should be a way limit the number of KA on a server - as I restart test-clients and redeploy my client apps they tend to accumulate. Shouldn't the KA name be unique and any reference to a KA with the same name recover the already created KA? Or shouldn't all KA created by a client app (web or standalone) die when the creating app terminates?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 10:13:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 10:13:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-1301) Update
 OSGi to be compatible with JBoss Modules 1.1 series
In-Reply-To: <970188.57854.1310766324068.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2034734244.85637.1311776003685.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617038#comment-12617038 ] 

Thomas Diesler edited comment on AS7-1301 at 7/27/11 10:12 AM:
---------------------------------------------------------------

The framework supports the notion of configurable system packages that can be loaded from the system bundle. 
Every bundle must be able load these packages from the system class loader 

In our implementation we define a system dependency for every host bundle. Currently I do it like this

{code}
// Add a system dependency
SystemPackagesPlugin plugin = injectedSystemPackages.getValue();
PathFilter systemPackagesFilter = plugin.getSystemPackageFilter();
PathFilter sysImportFilter = systemPackagesFilter;
PathFilter sysExportFilter = PathFilters.acceptAll();
moduleDependencies.add(DependencySpec.createSystemDependencySpec(sysImportFilter, sysExportFilter, null));
{code}

Note the 'null' for the system paths. I could define this set explicitly, which would require an update for every jdk version, right? Meanwhile, I think a fallback to JDKPaths.JDK is ok and we can revisit when I look at framework bootstrap performance. 

      was (Author: thomas.diesler):
    The framework supports the notion of configurable system packages that can be loaded from the system bundle. 
Every bundle must be able load these packages from the system class loader 

??The Framework must always delegate any package that starts with java. to the parent class loader.??

In our implementation we define a system dependency for every host bundle. Currently I do it like this

{code}
// Add a system dependency
SystemPackagesPlugin plugin = injectedSystemPackages.getValue();
PathFilter systemPackagesFilter = plugin.getSystemPackageFilter();
PathFilter sysImportFilter = systemPackagesFilter;
PathFilter sysExportFilter = PathFilters.acceptAll();
moduleDependencies.add(DependencySpec.createSystemDependencySpec(sysImportFilter, sysExportFilter, null));
{code}

Note the 'null' for the system paths. I could define this set explicitly, which would require an update for every jdk version, right? Meanwhile, I think a fallback to JDKPaths.JDK is ok and we can revisit when I look at framework bootstrap performance. 
  
> Update OSGi to be compatible with JBoss Modules 1.1 series
> ----------------------------------------------------------
>
>                 Key: AS7-1301
>                 URL: https://issues.jboss.org/browse/AS7-1301
>             Project: Application Server 7
>          Issue Type: Task
>          Components: OSGi
>            Reporter: David Lloyd
>            Assignee: Thomas Diesler
>             Fix For: 7.1.0.Alpha1
>
>
> JBoss Modules 1.1 has two significant changes.  First, jaxpmodule is eliminated.  Second, the system module is no more - instead there's a dependency type for the system class loader.
> I currently have an updated AS in my http://github.com/dmlloyd/jboss-as/tree/upgrades branch.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 10:18:24 2011
From: jira-events at lists.jboss.org (Burkhard Vogel (JIRA))
Date: Wed, 27 Jul 2011 10:18:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3152) Control of
 KnowledgeAgent instances
In-Reply-To: <413611220.80127.1311607043970.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1390187079.85642.1311776304327.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-3152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617044#comment-12617044 ] 

Burkhard Vogel commented on JBRULES-3152:
-----------------------------------------

Thinking about your comment that the user/application should control the Knowledge Agent - that would require a ServletContextListener? You'd have a use case how to correctly manage a KnowledgeAgent so that it is controlled during the application lifecycle?

> Control of KnowledgeAgent instances
> -----------------------------------
>
>                 Key: JBRULES-3152
>                 URL: https://issues.jboss.org/browse/JBRULES-3152
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.2.0.Final
>            Reporter: Burkhard Vogel
>            Assignee: Mark Proctor
>
> There should be a way limit the number of KA on a server - as I restart test-clients and redeploy my client apps they tend to accumulate. Shouldn't the KA name be unique and any reference to a KA with the same name recover the already created KA? Or shouldn't all KA created by a client app (web or standalone) die when the creating app terminates?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 10:18:24 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Wed, 27 Jul 2011 10:18:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1301) Update OSGi to be
 compatible with JBoss Modules 1.1 series
In-Reply-To: <970188.57854.1310766324068.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1831385727.85645.1311776304390.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617045#comment-12617045 ] 

Thomas Diesler commented on AS7-1301:
-------------------------------------

Thinking about it ... I always have an explicit import filter, so the set of paths does not need to be greater than what the filter accepts. So I could derive the paths from the filter. WDYT?

> Update OSGi to be compatible with JBoss Modules 1.1 series
> ----------------------------------------------------------
>
>                 Key: AS7-1301
>                 URL: https://issues.jboss.org/browse/AS7-1301
>             Project: Application Server 7
>          Issue Type: Task
>          Components: OSGi
>            Reporter: David Lloyd
>            Assignee: Thomas Diesler
>             Fix For: 7.1.0.Alpha1
>
>
> JBoss Modules 1.1 has two significant changes.  First, jaxpmodule is eliminated.  Second, the system module is no more - instead there's a dependency type for the system class loader.
> I currently have an updated AS in my http://github.com/dmlloyd/jboss-as/tree/upgrades branch.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 10:20:25 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 27 Jul 2011 10:20:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1301) Update OSGi to be
 compatible with JBoss Modules 1.1 series
In-Reply-To: <970188.57854.1310766324068.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <711366338.85664.1311776425401.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617047#comment-12617047 ] 

David Lloyd commented on AS7-1301:
----------------------------------

Using a dependency on javax.api+sun.jdk (plus whatever other javax. APIs your users expect) is essentially equivalent as the path calculation will only work on Sun JDK anyways.  In addition, the paths set returned by JDKPaths includes paths we specifically do *not* want in play from the system module in AS 7 as we override a bunch of APIs like JAXP, javax.annotation, JAXB, JAX-WS, javax.rmi, CORBA, etc.

Please see if using dependencies works first; JDKPaths is just a hack specifically for booting jboss-modules via -jar or -classpath and I'm trying to eliminate even that usage.

> Update OSGi to be compatible with JBoss Modules 1.1 series
> ----------------------------------------------------------
>
>                 Key: AS7-1301
>                 URL: https://issues.jboss.org/browse/AS7-1301
>             Project: Application Server 7
>          Issue Type: Task
>          Components: OSGi
>            Reporter: David Lloyd
>            Assignee: Thomas Diesler
>             Fix For: 7.1.0.Alpha1
>
>
> JBoss Modules 1.1 has two significant changes.  First, jaxpmodule is eliminated.  Second, the system module is no more - instead there's a dependency type for the system class loader.
> I currently have an updated AS in my http://github.com/dmlloyd/jboss-as/tree/upgrades branch.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 10:20:25 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 27 Jul 2011 10:20:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1301) Update OSGi to be
 compatible with JBoss Modules 1.1 series
In-Reply-To: <970188.57854.1310766324068.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <596534688.85670.1311776425605.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617048#comment-12617048 ] 

David Lloyd commented on AS7-1301:
----------------------------------

Yes, deriving the paths from the filter sounds like a fine idea, as long as the filter doesn't include any of the aforementioned javax or org.omg APIs.

> Update OSGi to be compatible with JBoss Modules 1.1 series
> ----------------------------------------------------------
>
>                 Key: AS7-1301
>                 URL: https://issues.jboss.org/browse/AS7-1301
>             Project: Application Server 7
>          Issue Type: Task
>          Components: OSGi
>            Reporter: David Lloyd
>            Assignee: Thomas Diesler
>             Fix For: 7.1.0.Alpha1
>
>
> JBoss Modules 1.1 has two significant changes.  First, jaxpmodule is eliminated.  Second, the system module is no more - instead there's a dependency type for the system class loader.
> I currently have an updated AS in my http://github.com/dmlloyd/jboss-as/tree/upgrades branch.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 10:47:23 2011
From: jira-events at lists.jboss.org (Karel Piwko (JIRA))
Date: Wed, 27 Jul 2011 10:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1415) Allow Arquillian
 tests to monitor server and deployment status explicitely
Message-ID: <1393981034.85772.1311778043667.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Allow Arquillian tests to monitor server and deployment status explicitely
--------------------------------------------------------------------------

                 Key: AS7-1415
                 URL: https://issues.jboss.org/browse/AS7-1415
             Project: Application Server 7
          Issue Type: Sub-task
          Components: Test Suite
    Affects Versions: 7.0.0.Final
            Reporter: Karel Piwko
            Assignee: Andrew Rubinger


Deployment can be checked via management API using ArquillianServiceObserver at least. 

The AS monitoring should use management API as well. These objects will be fully accessible in the testsuite.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 10:51:23 2011
From: jira-events at lists.jboss.org (Karel Piwko (JIRA))
Date: Wed, 27 Jul 2011 10:51:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1011) JBoss AS lifecycle
 controlling tests
In-Reply-To: <605868729.2361.1308035844057.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1978600570.85799.1311778283663.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617062#comment-12617062 ] 

Karel Piwko commented on AS7-1011:
----------------------------------

Marked as umbrella jira.

> JBoss AS lifecycle controlling tests
> ------------------------------------
>
>                 Key: AS7-1011
>                 URL: https://issues.jboss.org/browse/AS7-1011
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Test Suite
>    Affects Versions: 7.0.0.Beta3
>            Reporter: Karel Piwko
>            Assignee: Karel Piwko
>
> Create a test suite that uses Arquillian to control JBoss AS 7 lifecycle in a more precise way, that is:
> * DomainClient specific controller 
> * Asynchronous start, stop
> * Manual start after modifying a domain configuration
> * Monitoring of container and deployment status
> * Forced / programmable kill (cleanup to be investigated here though) 
> Some of the features would require modifications of Arquillian.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 10:55:25 2011
From: jira-events at lists.jboss.org (Karel Piwko (JIRA))
Date: Wed, 27 Jul 2011 10:55:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1415) Allow Arquillian
 tests to monitor server and deployment status explicitely
In-Reply-To: <1393981034.85772.1311778043667.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1422553760.85844.1311778525013.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karel Piwko updated AS7-1415:
-----------------------------

    Affects Version/s: 7.0.0.CR1
                           (was: 7.0.0.Final)


> Allow Arquillian tests to monitor server and deployment status explicitely
> --------------------------------------------------------------------------
>
>                 Key: AS7-1415
>                 URL: https://issues.jboss.org/browse/AS7-1415
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: Test Suite
>    Affects Versions: 7.0.0.CR1
>            Reporter: Karel Piwko
>            Assignee: Andrew Rubinger
>
> Deployment can be checked via management API using ArquillianServiceObserver at least. 
> The AS monitoring should use management API as well. These objects will be fully accessible in the testsuite.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 11:08:23 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Wed, 27 Jul 2011 11:08:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1416) Too many
 resources/properties in the domain api are read-only
Message-ID: <600423721.85894.1311779303791.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Too many resources/properties in the domain api are read-only
-------------------------------------------------------------

                 Key: AS7-1416
                 URL: https://issues.jboss.org/browse/AS7-1416
             Project: Application Server 7
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 7.0.0.Final
            Reporter: Heiko Rupp
            Assignee: Brian Stansberry


>From http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/003223.html:

just looked at the configuration side of the API again and most of the attibutes in there are read-only.

So I can not e.g. change the max post size for the http connector (*) via API - other than dropping the http
connector completely and re-creating it, which is nothing people will do (especially when there is no
":clone" operation that fills in the existing properties when not passed explicitly).

People will in this case just start hacking on standalone.xml and other files, which completely
renders the api void. Do we really want that?



--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 11:20:23 2011
From: jira-events at lists.jboss.org (Karel Piwko (JIRA))
Date: Wed, 27 Jul 2011 11:20:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1417) Provide Arquillian
 clustering example for domain server
Message-ID: <107527678.85919.1311780023761.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Provide Arquillian clustering example for domain server
-------------------------------------------------------

                 Key: AS7-1417
                 URL: https://issues.jboss.org/browse/AS7-1417
             Project: Application Server 7
          Issue Type: Sub-task
          Components: Test Suite
    Affects Versions: 7.0.0.CR1
            Reporter: Karel Piwko
            Assignee: Andrew Rubinger


Create an example which is using a domain controller and starts two domains on a single machine.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 11:20:23 2011
From: jira-events at lists.jboss.org (Karel Piwko (JIRA))
Date: Wed, 27 Jul 2011 11:20:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1417) Provide Arquillian
 clustering example for domain server
In-Reply-To: <107527678.85919.1311780023761.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <377725366.85923.1311780023853.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karel Piwko reassigned AS7-1417:
--------------------------------

    Assignee: Karel Piwko  (was: Andrew Rubinger)


> Provide Arquillian clustering example for domain server
> -------------------------------------------------------
>
>                 Key: AS7-1417
>                 URL: https://issues.jboss.org/browse/AS7-1417
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: Test Suite
>    Affects Versions: 7.0.0.CR1
>            Reporter: Karel Piwko
>            Assignee: Karel Piwko
>
> Create an example which is using a domain controller and starts two domains on a single machine.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 11:22:23 2011
From: jira-events at lists.jboss.org (Karel Piwko (JIRA))
Date: Wed, 27 Jul 2011 11:22:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1415) Allow Arquillian
 tests to monitor server and deployment status explicitly
In-Reply-To: <1393981034.85772.1311778043667.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <333126574.85926.1311780143754.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karel Piwko updated AS7-1415:
-----------------------------

    Summary: Allow Arquillian tests to monitor server and deployment status explicitly  (was: Allow Arquillian tests to monitor server and deployment status explicitely)


> Allow Arquillian tests to monitor server and deployment status explicitly
> -------------------------------------------------------------------------
>
>                 Key: AS7-1415
>                 URL: https://issues.jboss.org/browse/AS7-1415
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: Test Suite
>    Affects Versions: 7.0.0.CR1
>            Reporter: Karel Piwko
>            Assignee: Andrew Rubinger
>
> Deployment can be checked via management API using ArquillianServiceObserver at least. 
> The AS monitoring should use management API as well. These objects will be fully accessible in the testsuite.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 11:22:23 2011
From: jira-events at lists.jboss.org (Karel Piwko (JIRA))
Date: Wed, 27 Jul 2011 11:22:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1418) Provide Arquillian
 clustering example for standalone server
Message-ID: <1959949060.85930.1311780143888.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Provide Arquillian clustering example for standalone server
-----------------------------------------------------------

                 Key: AS7-1418
                 URL: https://issues.jboss.org/browse/AS7-1418
             Project: Application Server 7
          Issue Type: Sub-task
          Components: Test Suite
    Affects Versions: 7.0.0.Beta3
            Reporter: Karel Piwko
            Assignee: Karel Piwko


Create a clustering example which is starting two independent standalone nodes.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 11:50:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 27 Jul 2011 11:50:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1419) AbstractClassFactory
 runs into NullPointerException
Message-ID: <1872885577.86139.1311781823613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

AbstractClassFactory runs into NullPointerException
---------------------------------------------------

                 Key: AS7-1419
                 URL: https://issues.jboss.org/browse/AS7-1419
             Project: Application Server 7
          Issue Type: Bug
          Components: EE
    Affects Versions: 7.0.0.Final
            Reporter: jaikiran pai
            Assignee: David Lloyd


{code}
Caused by: java.lang.NullPointerException
          at org.jboss.invocation.proxy.AbstractClassFactory.defineClass(AbstractClassFactory.java:150)
          at org.jboss.invocation.proxy.AbstractProxyFactory.getCachedMethods(AbstractProxyFactory.java:118)
          at org.jboss.as.ejb3.component.stateless.StatelessComponentDescription$2.configure(StatelessComponentDescription.java:121)
          at org.jboss.as.ee.component.ComponentDescription$DefaultFirstConfigurator.configure(ComponentDescription.java:778)
          at org.jboss.as.ee.component.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:65)
          at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
          ... 5 more

{code}

One scenario where this can happen is if the business interface of a bean is from the JDK. Referenced forum thread has more details.

 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 11:52:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 27 Jul 2011 11:52:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1419) AbstractClassFactory
 runs into NullPointerException
In-Reply-To: <1872885577.86139.1311781823613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <753614629.86145.1311781943699.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned AS7-1419:
--------------------------------

    Assignee: Stuart Douglas  (was: David Lloyd)


Can you look into this Stuart?

> AbstractClassFactory runs into NullPointerException
> ---------------------------------------------------
>
>                 Key: AS7-1419
>                 URL: https://issues.jboss.org/browse/AS7-1419
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 7.0.0.Final
>            Reporter: jaikiran pai
>            Assignee: Stuart Douglas
>
> {code}
> Caused by: java.lang.NullPointerException
>           at org.jboss.invocation.proxy.AbstractClassFactory.defineClass(AbstractClassFactory.java:150)
>           at org.jboss.invocation.proxy.AbstractProxyFactory.getCachedMethods(AbstractProxyFactory.java:118)
>           at org.jboss.as.ejb3.component.stateless.StatelessComponentDescription$2.configure(StatelessComponentDescription.java:121)
>           at org.jboss.as.ee.component.ComponentDescription$DefaultFirstConfigurator.configure(ComponentDescription.java:778)
>           at org.jboss.as.ee.component.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:65)
>           at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
>           ... 5 more
> {code}
> One scenario where this can happen is if the business interface of a bean is from the JDK. Referenced forum thread has more details.
>  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 11:58:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 27 Jul 2011 11:58:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1352) JCA thread pools
 must be blocking
In-Reply-To: <29744231.69171.1311168323839.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1356308373.86150.1311782303655.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617086#comment-12617086 ] 

Jesper Pedersen commented on AS7-1352:
--------------------------------------

You should add some additional checks, such that you are sure only to update a thread pool definition.

Also you could override the blocking attribute once the thread pools are written (writeDefaultWorkManager).

> JCA thread pools must be blocking
> ---------------------------------
>
>                 Key: AS7-1352
>                 URL: https://issues.jboss.org/browse/AS7-1352
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 7.0.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.Alpha1
>
>
> The "blocking" attribute for the JCA thread pools should be ignored as it should always be true.
> In order to align with other subsystems we will just ignore any value set by the user, and hard code to true.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 12:29:23 2011
From: jira-events at lists.jboss.org (Brad Maxwell (JIRA))
Date: Wed, 27 Jul 2011 12:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (EJBTHREE-2264) Cannot specify
 default loadBalancePolicy for Clustered EJB3s
Message-ID: <367334537.86208.1311784163930.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/EJBTHREE-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brad Maxwell moved JBPAPP-6912 to EJBTHREE-2264:
------------------------------------------------

                     Project: EJB 3.0  (was: JBoss Enterprise Application Platform)
                         Key: EJBTHREE-2264  (was: JBPAPP-6912)
           Affects Version/s: bom-eap5-1.0.2
                                  (was: EAP_EWP 5.1.0)
    Component Fix Version(s): proxy-clustered 1.0.4
                 Component/s: proxy-clustered
                                  (was: Clustering)
                    Security:     (was: Public)
               Fix Version/s: bom-eap5-1.0.3
                                  (was: EAP_EWP 5.1.2)
              Docs QE Status:   (was: NEW)


> Cannot specify default loadBalancePolicy for Clustered EJB3s
> ------------------------------------------------------------
>
>                 Key: EJBTHREE-2264
>                 URL: https://issues.jboss.org/browse/EJBTHREE-2264
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: proxy-clustered
>    Affects Versions: bom-eap5-1.0.2
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>             Fix For: bom-eap5-1.0.3
>
>
> Tried using ejb3-interceptors-aop.xml, however it seems you cannot modify @Clustered annotations, since the EJBs already have @Clustered on them.
> This file is where the defaults are currently, This file can be modified to allow you to specify the default loadBalancePolicy to be specified and the default sticky load balance policy in the $JBOSS_HOME/server/$PROFILE/deployers/ejb3.deployer/META-INF/ejb3-deployers-jboss-beans.xml
> jboss-ejb3-proxy-clustered-1.0.3/src/main/java/org/jboss/ejb3/proxy/clustered/registry/ProxyClusteringRegistry.java

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 12:35:23 2011
From: jira-events at lists.jboss.org (Brad Maxwell (JIRA))
Date: Wed, 27 Jul 2011 12:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-2264) Cannot specify
 default loadBalancePolicy for Clustered EJB3s
Message-ID: <2064151963.86212.1311784523896.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/EJBTHREE-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brad Maxwell updated EJBTHREE-2264:
-----------------------------------

    Component Fix Version(s): proxy-clustered 1.0.5  (was: proxy-clustered 1.0.4)


> Cannot specify default loadBalancePolicy for Clustered EJB3s
> ------------------------------------------------------------
>
>                 Key: EJBTHREE-2264
>                 URL: https://issues.jboss.org/browse/EJBTHREE-2264
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: proxy-clustered
>    Affects Versions: bom-eap5-1.0.2
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>             Fix For: bom-eap5-1.0.3
>
>
> Tried using ejb3-interceptors-aop.xml, however it seems you cannot modify @Clustered annotations, since the EJBs already have @Clustered on them.
> This file is where the defaults are currently, This file can be modified to allow you to specify the default loadBalancePolicy to be specified and the default sticky load balance policy in the $JBOSS_HOME/server/$PROFILE/deployers/ejb3.deployer/META-INF/ejb3-deployers-jboss-beans.xml
> jboss-ejb3-proxy-clustered-1.0.3/src/main/java/org/jboss/ejb3/proxy/clustered/registry/ProxyClusteringRegistry.java

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 14:43:23 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Wed, 27 Jul 2011 14:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1420) Too few subsystems
 actually export metrics
Message-ID: <376786570.86428.1311792203657.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Too few subsystems actually export metrics
------------------------------------------

                 Key: AS7-1420
                 URL: https://issues.jboss.org/browse/AS7-1420
             Project: Application Server 7
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 7.0.0.Final
            Reporter: Heiko Rupp
            Assignee: Brian Stansberry


Most subsystems do not expose metrics or if the attributes are exported via Domain API, they are not filled with real values and so on.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 14:47:23 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Wed, 27 Jul 2011 14:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1421) Modcluster subsystem
 has broken :read-resource-description
Message-ID: <1749021724.86448.1311792443737.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Modcluster subsystem has broken :read-resource-description
----------------------------------------------------------

                 Key: AS7-1421
                 URL: https://issues.jboss.org/browse/AS7-1421
             Project: Application Server 7
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 7.0.0.Final
            Reporter: Heiko Rupp
            Assignee: Brian Stansberry


[domain at localhost:9999 subsystem=modcluster] :read-resource-description
{
    "outcome" => "success",
    "result" => {
        "description" => "The configuration of the modcluster subsystem.",
        "head-comment-allowed" => true,
        "tail-comment-allowed" => true,
        "namespace" => "urn:jboss:domain:modcluster:1.0",
        "attributes" => {"mod-cluster-config" => {
            "type" => OBJECT,
            "description" => "The common modcluster configuration.",
            "required" => false,
            "access-type" => "read-only",
            "storage" => "configuration"
        }}
    }
}

is not usable at all to use for management operations.
Also attributes of mod-cluster-config should directly live in 'attributes'. There is no point in adding one more level here.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 15:19:23 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Wed, 27 Jul 2011 15:19:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1422) Add a generic query
	facility
Message-ID: <1265214263.86576.1311794363910.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Add a generic query facility
----------------------------

                 Key: AS7-1422
                 URL: https://issues.jboss.org/browse/AS7-1422
             Project: Application Server 7
          Issue Type: Feature Request
          Components: Domain Management
    Affects Versions: 7.0.0.Final
            Reporter: Heiko Rupp
            Assignee: Brian Stansberry


To find out, which e.g. jdbc drivers are deployed on a server group, I have to visit each managed server and query it. This is cumbersome
- first the server group should have the same driver for all servers, so asking the server group should be enough
- as the server group does not even know its connected managed servers (there is no :list-servers) operation, I need to potentially loop over the whole domain including tons of remote HC in order to query for e.g. the jdbc drivers or other stuff

There should be a mechanism to fire queries at which then get relayed to the HCs and the answers combined and returned.

Still I don't get why if a server-group is meant to contain an identical configuration for all its managed servers (besides VM params, ports and IPs) it does not just have "proxy methods" like :installed-drivers-list or :server-list etc.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 15:31:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 27 Jul 2011 15:31:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-566) Support
 for pluggable JPA providers
In-Reply-To: <282632663.33198.1300384486238.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <26145267.86602.1311795083944.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12614607#comment-12614607 ] 

Scott Marlow edited comment on AS7-566 at 7/27/11 3:30 PM:
-----------------------------------------------------------

Comment deleted.  I'll instead describe the changes in https://docs.jboss.org/author/display/AS7/JPA+Reference+Guide (after the code change is merged to as7).  

      was (Author: smarlow):
    Will need a jboss-deployment-structure.xml rather than MANIFEST.MF entries.  Also need one more change for locating PersistenceProviderAdaptor implementations (the integration classes).  Will need a META-INF/services entry in each of the integration modules.

jboss-as-jpa-hibernate3.jar/META-INF/services/org.jboss.as.jpa.spi.PersistenceProviderAdaptor will contain:
{quote}
org.jboss.as.jpa.hibernate3.HibernatePersistenceProviderAdaptor
{quote}

jboss-deployment-structure.xml will contain:
{code}
<jboss-deployment-structure>
   <deployment>
        <exclusions>
          <module name="org.hibernate"/>
        </exclusions>
        <dependencies>
          <module name="org.jboss.as.jpa.hibernate3"/>
        </dependencies>
    </deployment>
</jboss-deployment-structure>
{code}
  
> Support for pluggable JPA providers
> -----------------------------------
>
>                 Key: AS7-566
>                 URL: https://issues.jboss.org/browse/AS7-566
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: JPA / Hibernate
>            Reporter: David Lloyd
>            Assignee: Scott Marlow
>             Fix For: 7.1.0.Alpha1
>
>
> Maybe we could have a service per persistence provider that is based on a configuration settings.
> Questions:
> 1.  Where do the persistent provider jars go in the system?  Should we deploy them somehow?
> 2.  Each persistence.xml specifies the javax.persistence.spi.PersistenceProvider class name (via provider element) that it will use (defaults to whatever the AS7 default persistence provider).  The persistence.xml also allows vendor properties to be specified.  We could have an optional property "org.jboss.jpa.provider.versionSpecifier" that matches a specific version of the provider.
> Is this the best way to allow different versions of persistence provider?
> 3.  How could we best dynamically build a ModuleDependency on a persistence provider jar that 
> could be injected into a deployment (perhaps from JPADependencyProcessor)?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 15:35:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 27 Jul 2011 15:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-566) Support for
 pluggable JPA providers
In-Reply-To: <282632663.33198.1300384486238.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1042415039.86616.1311795323820.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617122#comment-12617122 ] 

Scott Marlow commented on AS7-566:
----------------------------------

Integration support for Hibernate 4, will continue to be built in (Hibernate 4 jars are included with AS7).  For Hibernate 3, the integration code will be in AS7 but the Hibernate 3 jars either need to be copied in or packaged with the application deployment.



> Support for pluggable JPA providers
> -----------------------------------
>
>                 Key: AS7-566
>                 URL: https://issues.jboss.org/browse/AS7-566
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: JPA / Hibernate
>            Reporter: David Lloyd
>            Assignee: Scott Marlow
>             Fix For: 7.1.0.Alpha1
>
>
> Maybe we could have a service per persistence provider that is based on a configuration settings.
> Questions:
> 1.  Where do the persistent provider jars go in the system?  Should we deploy them somehow?
> 2.  Each persistence.xml specifies the javax.persistence.spi.PersistenceProvider class name (via provider element) that it will use (defaults to whatever the AS7 default persistence provider).  The persistence.xml also allows vendor properties to be specified.  We could have an optional property "org.jboss.jpa.provider.versionSpecifier" that matches a specific version of the provider.
> Is this the best way to allow different versions of persistence provider?
> 3.  How could we best dynamically build a ModuleDependency on a persistence provider jar that 
> could be injected into a deployment (perhaps from JPADependencyProcessor)?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 15:41:23 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Wed, 27 Jul 2011 15:41:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-951)
 :installed-drivers-list should not be enabled for subsystem=datasource in
 domain mode
In-Reply-To: <181860081.8766.1307452559689.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1796945302.86652.1311795683718.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617125#comment-12617125 ] 

Heiko Rupp commented on AS7-951:
--------------------------------

Still borked in 700 final, but in a different way:
[domain at localhost:9999 subsystem=datasources] :installed-drivers-list
{
    "outcome" => "success",
    "result" => "no metrics available"
}

> :installed-drivers-list should not be enabled for subsystem=datasource in domain mode
> -------------------------------------------------------------------------------------
>
>                 Key: AS7-951
>                 URL: https://issues.jboss.org/browse/AS7-951
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Rupp
>
> [15:05:42] <+pilhuhn> [domain at localhost:9999 subsystem=datasources] :installed-drivers-list
> [15:05:42] <+pilhuhn> {
> [15:05:42] <+pilhuhn>    "outcome" => "success",
> [15:05:42] <+pilhuhn>    "result" => undefined,
> [15:05:56] <+pilhuhn> Or is that a domain vs standalone thing again? Let me check that
> [15:06:20] <hbraun> in domain mode this needs to executed against a host
> [15:07:01] <+pilhuhn> hm. Does that make sense?
> [15:07:23] <hbraun> yes, the drives can be installed as deployments
> [15:07:34] <hbraun> which is a host thing
> [15:08:34] <+pilhuhn> not server-group?
> [15:08:52] <hbraun> no, host
> [15:09:02] <+pilhuhn> And then I would expect that the /profile=x/subysy=ds/ would not support :installed-driver-list
> [15:09:02] <hbraun> the host installes it as a runtime component
> [15:09:15] <hbraun> yes, that's right
> [15:09:22] <hbraun> it shouldn't

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 17:01:24 2011
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Wed, 27 Jul 2011 17:01:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1320) Parsing issue in
 Logging Subsystem - level is required by parser, but not schema
In-Reply-To: <1929200590.60734.1311003623635.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <66565685.86860.1311800484503.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins resolved AS7-1320.
--------------------------------

    Resolution: Done


> Parsing issue in Logging Subsystem - level is required by parser, but not schema
> --------------------------------------------------------------------------------
>
>                 Key: AS7-1320
>                 URL: https://issues.jboss.org/browse/AS7-1320
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.0.0.Final
>            Reporter: John Bailey
>            Assignee: James Perkins
>             Fix For: 7.0.1.Final
>
>
> There seems to be an issue with the handler element parsing that expects the level and encoding to be defined, but they are both listed as minOccurs="0" in the schema.  
> Causes stack traces like the following:
> 10:31:32,371 ERROR [stderr] Exception in thread "Controller Boot Thread" java.lang.RuntimeException: org.jboss.as.controller.persistence.ConfigurationPersistenceException: Failed to parse configuration
> 10:31:32,371 ERROR [stderr] 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:89)
> 10:31:32,386 ERROR [stderr] 	at java.lang.Thread.run(Unknown Source)
> 10:31:32,386 ERROR [stderr] Caused by: org.jboss.as.controller.persistence.ConfigurationPersistenceException: Failed to parse configuration
> 10:31:32,386 ERROR [stderr] 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:115)
> 10:31:32,386 ERROR [stderr] 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:104)
> 10:31:32,386 ERROR [stderr] 	at org.jboss.as.server.ServerService.boot(ServerService.java:193)
> 10:31:32,386 ERROR [stderr] 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:83)
> 10:31:32,402 ERROR [stderr] 	... 1 more
> 10:31:32,402 ERROR [stderr] Caused by: java.lang.IllegalArgumentException: newValue is null
> 10:31:32,417 ERROR [stderr] 	at org.jboss.dmr.ModelNode.set(ModelNode.java:349)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.logging.LoggingSubsystemParser.parseSizeRotatingHandlerElement(LoggingSubsystemParser.java:704)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.logging.LoggingSubsystemParser.readElement(LoggingSubsystemParser.java:145)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.logging.LoggingSubsystemParser.readElement(LoggingSubsystemParser.java:84)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:100)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.controller.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:311)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.controller.parsing.StandaloneXml.readServerElement(StandaloneXml.java:163)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.controller.parsing.StandaloneXml.readElement(StandaloneXml.java:91)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.controller.parsing.StandaloneXml.readElement(StandaloneXml.java:79)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:100)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:59)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:107)
> 10:31:32,417 ERROR [stderr] 	... 4 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 17:01:24 2011
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Wed, 27 Jul 2011 17:01:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-1320) Parsing issue in
 Logging Subsystem - level is required by parser, but not schema
In-Reply-To: <1929200590.60734.1311003623635.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <158543684.86870.1311800484935.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins closed AS7-1320.
------------------------------



> Parsing issue in Logging Subsystem - level is required by parser, but not schema
> --------------------------------------------------------------------------------
>
>                 Key: AS7-1320
>                 URL: https://issues.jboss.org/browse/AS7-1320
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.0.0.Final
>            Reporter: John Bailey
>            Assignee: James Perkins
>             Fix For: 7.0.1.Final
>
>
> There seems to be an issue with the handler element parsing that expects the level and encoding to be defined, but they are both listed as minOccurs="0" in the schema.  
> Causes stack traces like the following:
> 10:31:32,371 ERROR [stderr] Exception in thread "Controller Boot Thread" java.lang.RuntimeException: org.jboss.as.controller.persistence.ConfigurationPersistenceException: Failed to parse configuration
> 10:31:32,371 ERROR [stderr] 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:89)
> 10:31:32,386 ERROR [stderr] 	at java.lang.Thread.run(Unknown Source)
> 10:31:32,386 ERROR [stderr] Caused by: org.jboss.as.controller.persistence.ConfigurationPersistenceException: Failed to parse configuration
> 10:31:32,386 ERROR [stderr] 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:115)
> 10:31:32,386 ERROR [stderr] 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:104)
> 10:31:32,386 ERROR [stderr] 	at org.jboss.as.server.ServerService.boot(ServerService.java:193)
> 10:31:32,386 ERROR [stderr] 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:83)
> 10:31:32,402 ERROR [stderr] 	... 1 more
> 10:31:32,402 ERROR [stderr] Caused by: java.lang.IllegalArgumentException: newValue is null
> 10:31:32,417 ERROR [stderr] 	at org.jboss.dmr.ModelNode.set(ModelNode.java:349)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.logging.LoggingSubsystemParser.parseSizeRotatingHandlerElement(LoggingSubsystemParser.java:704)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.logging.LoggingSubsystemParser.readElement(LoggingSubsystemParser.java:145)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.logging.LoggingSubsystemParser.readElement(LoggingSubsystemParser.java:84)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:100)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.controller.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:311)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.controller.parsing.StandaloneXml.readServerElement(StandaloneXml.java:163)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.controller.parsing.StandaloneXml.readElement(StandaloneXml.java:91)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.controller.parsing.StandaloneXml.readElement(StandaloneXml.java:79)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:100)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:59)
> 10:31:32,417 ERROR [stderr] 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:107)
> 10:31:32,417 ERROR [stderr] 	... 4 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 17:30:23 2011
From: jira-events at lists.jboss.org (Michael Gafron (JIRA))
Date: Wed, 27 Jul 2011 17:30:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-9423) Recieving
 ClassNotFoundException with sqljdbc4.jar using JBoss 6
Message-ID: <1480197348.86971.1311802223733.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Recieving ClassNotFoundException with sqljdbc4.jar using JBoss 6
----------------------------------------------------------------

                 Key: JBAS-9423
                 URL: https://issues.jboss.org/browse/JBAS-9423
             Project: Legacy JBoss Application Server 6 
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.0.Final
         Environment: Laptop with Windows 7 Ultimate, x64 Intel Core i7 - 2.3ghz, 16 GB ram, 2048 video card, manufacturer = Lenovo.
JBoss 6.0, Eclipse Helios 4.2.3 SP2.
            Reporter: Michael Gafron
            Priority: Critical


Deploying an EAR file to JBoss 6.  If I use eclipse the project starts successfully. If I deploy outside of eclipse (i.e. place .ear in the deploy directory) I receive the following message:

ERROR:

  Deployment "vfs:///C:/work/jboss-6.0.0.Final_LocalCopy/jboss-6.0.0.Final/server/default/deploy/NapersoftCCM_JBOSS60_EAR.ear" is in error due to the following reason(s): java.lang.ClassNotFoundException: sqljdbc4.jar.com.microsoft.sqlserver.jdbc.XAReturnValue

The sqljdbc4.jar file is located in the ..\jboss-6.0.0.Final\server\default\lib directory. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 17:41:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 27 Jul 2011 17:41:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1350) Add management
 operations to assign/unassign handlers from loggers and async handlers.
In-Reply-To: <788349166.68808.1311164783691.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2146486565.87010.1311802883654.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617151#comment-12617151 ] 

David Lloyd commented on AS7-1350:
----------------------------------

Some more feedback:

* The operation should be the same "add-handler"/"remove-handler" whether the target is a logger, the root logger, or a handler.
* We should be able to use address to differentiate between the target types; each logger and handler should be its own resource, and the root logger should also be its own resource, if they aren't already.

Having six operations for this seems non-optimal.

> Add management operations to assign/unassign handlers from loggers and async handlers.
> --------------------------------------------------------------------------------------
>
>                 Key: AS7-1350
>                 URL: https://issues.jboss.org/browse/AS7-1350
>             Project: Application Server 7
>          Issue Type: Feature Request
>    Affects Versions: 7.0.0.Final
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>             Fix For: 7.1.0.Alpha1
>
>
> Proposed new management operations:
> For Async Handler:
> assign-subhandler
> unassign-subhandler
> For Root Logger:
> root-logger-assign-handler
> root-logger-unassign-handler
> For other Loggers:
> assign-handler
> unassign-handler

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 17:44:23 2011
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Wed, 27 Jul 2011 17:44:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-993) Remove noise from
 start/stop console log
In-Reply-To: <1507978724.19176.1307714879325.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <636945382.87015.1311803063712.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617153#comment-12617153 ] 

Jason Greene commented on AS7-993:
----------------------------------

We should discuss this on the ML. All of those except for the bootstrap log handlers I think are informative. Well arguably ARJUNA32018 needs a better message or a single message

> Remove noise from start/stop console log
> ----------------------------------------
>
>                 Key: AS7-993
>                 URL: https://issues.jboss.org/browse/AS7-993
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: Max Rydahl Andersen
>
> latest trunk still prints the following on Ctrl+C/Stop:
> 16:05:20,700 INFO  [org.jboss.as.osgi] (MSC service thread 1-3) Stopping OSGi Framework
> 16:05:20,738 INFO  [org.jboss.as.logging] Restored bootstrap log handlers
> 16:05:20,768 INFO  [com.arjuna.ats.jbossatx] ARJUNA32018: Destroying TransactionManagerService
> 16:05:20,769 INFO  [com.arjuna.ats.jbossatx] ARJUNA32014: Stopping transaction recovery manager
> 16:05:20,802 INFO  [org.hornetq.core.server.impl.HornetQServerImpl] HornetQ Server version 2.2.2.Final (super-hornetq-fighter, 122) [0462442a-936a-11e0-ac45-001c42000009] stopped
> 16:05:20,805 INFO  [org.jboss.as] JBoss AS 7.0.0.Beta4-SNAPSHOT "(TBD)" stopped in 102ms
> Besides the last one why do we need to info log stopping of osgi, log handlers, arjuna and recovery managers and hornetq ?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 17:46:23 2011
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Wed, 27 Jul 2011 17:46:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1208) poor error message
 with type in logging
In-Reply-To: <512096716.37430.1309959143765.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2080431851.87022.1311803183866.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins resolved AS7-1208.
--------------------------------

    Fix Version/s: 7.0.1.Final
       Resolution: Done


> poor error message with type in logging
> ---------------------------------------
>
>                 Key: AS7-1208
>                 URL: https://issues.jboss.org/browse/AS7-1208
>             Project: Application Server 7
>          Issue Type: Quality Risk
>            Reporter: Bill Burke
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 7.0.1.Final
>
>
> I had a typo in logging config for standalone.xml  "TRACEy" instead of "TRACE"
> I got the obscure message of:
> 09:26:08,720 WARN  [org.jboss.as.controller] Operation ("add") failed - address: ([
>     ("subsystem" => "logging"),
>     ("periodic-rotating-file-handler" => "FILE")
> ])

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 17:46:23 2011
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Wed, 27 Jul 2011 17:46:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-1208) poor error message
 with type in logging
In-Reply-To: <512096716.37430.1309959143765.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <953337378.87026.1311803183961.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins closed AS7-1208.
------------------------------



> poor error message with type in logging
> ---------------------------------------
>
>                 Key: AS7-1208
>                 URL: https://issues.jboss.org/browse/AS7-1208
>             Project: Application Server 7
>          Issue Type: Quality Risk
>            Reporter: Bill Burke
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 7.0.1.Final
>
>
> I had a typo in logging config for standalone.xml  "TRACEy" instead of "TRACE"
> I got the obscure message of:
> 09:26:08,720 WARN  [org.jboss.as.controller] Operation ("add") failed - address: ([
>     ("subsystem" => "logging"),
>     ("periodic-rotating-file-handler" => "FILE")
> ])

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 17:50:23 2011
From: jira-events at lists.jboss.org (Jason Greene (JIRA))
Date: Wed, 27 Jul 2011 17:50:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1407) JNDI view operation
 doesn't show all entries
In-Reply-To: <1759022158.82897.1311694223635.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1857554726.87032.1311803423673.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Greene reassigned AS7-1407:
---------------------------------

    Assignee: John Bailey  (was: Brian Stansberry)


> JNDI view operation doesn't show all entries
> --------------------------------------------
>
>                 Key: AS7-1407
>                 URL: https://issues.jboss.org/browse/AS7-1407
>             Project: Application Server 7
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: John Bailey
>
> don't ask me why, but a queue (java:/jboss/queues/myQueue) for instance is not shown. Same thing for resource adapter, etc.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 18:48:23 2011
From: jira-events at lists.jboss.org (=?UTF-8?Q?J=C3=A9r=C3=A9mie_Lagarde_=28JIRA=29?=)
Date: Wed, 27 Jul 2011 18:48:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3157) Add information
 such as line number or source code in VerifierComponent
Message-ID: <121374239.87050.1311806903613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Add information such as line number or source code in VerifierComponent
-----------------------------------------------------------------------

                 Key: JBRULES-3157
                 URL: https://issues.jboss.org/browse/JBRULES-3157
             Project: Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-verifier
            Reporter: J?r?mie Lagarde
            Assignee: Mark Proctor
            Priority: Optional


We can link the VerifierComponent with their descriptions.
This provides a simple access to information from the descriptions of the component or its associated VerifierMessageBase.

I tested this by adding to the VerifierComponent  constructor the BaseDescr :
public abstract class VerifierComponent implements Comparable<VerifierComponent>, Cause {
    private BaseDescr descr;
    public VerifierComponent(BaseDescr descr) {
        this.descr = descr;
    }
...
}

And integrate that in all Visitors.
This seems to work. ( https://github.com/jerr/drools/tree/line-number-in-verifier )

What do you think of this, I can add test cases and provide a patch or git pull request.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Wed Jul 27 19:17:24 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Wed, 27 Jul 2011 19:17:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1419) AbstractClassFactory
 runs into NullPointerException
In-Reply-To: <1872885577.86139.1311781823613.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <720263381.87065.1311808644047.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved AS7-1419.
---------------------------------

    Fix Version/s: 7.0.1.Final
       Resolution: Done


> AbstractClassFactory runs into NullPointerException
> ---------------------------------------------------
>
>                 Key: AS7-1419
>                 URL: https://issues.jboss.org/browse/AS7-1419
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 7.0.0.Final
>            Reporter: jaikiran pai
>            Assignee: Stuart Douglas
>             Fix For: 7.0.1.Final
>
>
> {code}
> Caused by: java.lang.NullPointerException
>           at org.jboss.invocation.proxy.AbstractClassFactory.defineClass(AbstractClassFactory.java:150)
>           at org.jboss.invocation.proxy.AbstractProxyFactory.getCachedMethods(AbstractProxyFactory.java:118)
>           at org.jboss.as.ejb3.component.stateless.StatelessComponentDescription$2.configure(StatelessComponentDescription.java:121)
>           at org.jboss.as.ee.component.ComponentDescription$DefaultFirstConfigurator.configure(ComponentDescription.java:778)
>           at org.jboss.as.ee.component.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:65)
>           at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
>           ... 5 more
> {code}
> One scenario where this can happen is if the business interface of a bean is from the JDK. Referenced forum thread has more details.
>  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 19:29:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Wed, 27 Jul 2011 19:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1406) Classloading /
 module issue with using resteasy-jackson-provider and joda classes
In-Reply-To: <2129812508.82863.1311693143675.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1456265802.87072.1311809363974.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned AS7-1406:
-----------------------------------

    Assignee: Stuart Douglas  (was: David Lloyd)


> Classloading / module issue with using resteasy-jackson-provider and joda classes
> ---------------------------------------------------------------------------------
>
>                 Key: AS7-1406
>                 URL: https://issues.jboss.org/browse/AS7-1406
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Modules
>    Affects Versions: 7.0.0.Final
>            Reporter: Sebastian Jancke
>            Assignee: Stuart Douglas
>              Labels: classloader, jodatime, resteasy
>
> Classes of org.joda.time cannot be deserialized from JSON with the standard, built-in JodaDeserializer of org.codehaus.jackson, used by resteasy in the resteasy-jackson-provider.
> Cause: jackson-mapper-asl (and possibly others) have no module-dependency to a (missing) module org.joda.time and thus cannot load the classes.
> Stacktrace:
> lang.ClassNotFoundException: org.joda.time.ReadableInstant from [Module "org.codehaus.jackson.jackson-mapper-asl:main" from local module loader @4ce66
> f56 (roots: OBFUSCATED\jboss-as-7.0.0.Final\modules)]
>         at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
>         at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
>         at org.codehaus.jackson.map.ext.JodaDeserializers.provide(JodaDeserializers.java:32) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.ext.OptionalHandlerFactory.findDeserializer(OptionalHandlerFactory.java:118) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.BasicDeserializerFactory.createBeanDeserializer(BasicDeserializerFactory.java:358) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.BeanDeserializerFactory.createBeanDeserializer(BeanDeserializerFactory.java:57) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.StdDeserializerProvider._createDeserializer(StdDeserializerProvider.java:342) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.StdDeserializerProvider._createAndCache2(StdDeserializerProvider.java:264) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.StdDeserializerProvider._createAndCacheValueDeserializer(StdDeserializerProvider.java:244) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.StdDeserializerProvider.findValueDeserializer(StdDeserializerProvider.java:111) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.StdDeserializer.findDeserializer(StdDeserializer.java:482) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.BeanDeserializer.resolve(BeanDeserializer.java:271) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.StdDeserializerProvider._resolveDeserializer(StdDeserializerProvider.java:348) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.StdDeserializerProvider._createAndCache2(StdDeserializerProvider.java:303) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.StdDeserializerProvider._createAndCacheValueDeserializer(StdDeserializerProvider.java:244) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.StdDeserializerProvider.findValueDeserializer(StdDeserializerProvider.java:111) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.jsontype.impl.TypeDeserializerBase._findDeserializer(TypeDeserializerBase.java:77) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.jsontype.impl.AsPropertyTypeDeserializer.deserializeTypedFromObject(AsPropertyTypeDeserializer.java:65) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.AbstractDeserializer.deserializeWithType(AbstractDeserializer.java:81) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:147) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.SettableBeanProperty$MethodProperty.deserializeAndSet(SettableBeanProperty.java:237) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:496) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.deser.BeanDeserializer.deserialize(BeanDeserializer.java:350) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.ObjectMapper._readValue(ObjectMapper.java:1961) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.map.ObjectMapper.readValue(ObjectMapper.java:889) [jackson-mapper-asl-1.6.3.jar:1.6.3]
>         at org.codehaus.jackson.jaxrs.JacksonJsonProvider.readFrom(JacksonJsonProvider.java:410)
>         at org.jboss.resteasy.core.interception.MessageBodyReaderContextImpl.proceed(MessageBodyReaderContextImpl.java:105) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.plugins.interceptors.encoding.GZIPDecodingInterceptor.read(GZIPDecodingInterceptor.java:61) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.core.interception.MessageBodyReaderContextImpl.proceed(MessageBodyReaderContextImpl.java:108) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.plugins.interceptors.encoding.GZIPDecodingInterceptor.read(GZIPDecodingInterceptor.java:61) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.core.interception.MessageBodyReaderContextImpl.proceed(MessageBodyReaderContextImpl.java:108) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.core.MessageBodyParameterInjector.inject(MessageBodyParameterInjector.java:168) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.core.MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:114) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:255) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:220) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:209) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:519) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:496) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:119) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.2.1.GA.jar:]
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:67) [weld-core-1.1.2.AS7.jar:2011-07-06 12
> :26]
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:480) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.0.0.Final.jar:7.0.0.Final]
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
>         at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 19:31:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Wed, 27 Jul 2011 19:31:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1408) Missing
 module-dependency breacks reconfiguring jackson ObjectMapper with using
 resteasy-jackson-provider
In-Reply-To: <410650910.82917.1311695243605.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <392885951.87078.1311809483719.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned AS7-1408:
-----------------------------------

    Assignee: Stuart Douglas  (was: David Lloyd)


> Missing module-dependency breacks reconfiguring jackson ObjectMapper with using resteasy-jackson-provider
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-1408
>                 URL: https://issues.jboss.org/browse/AS7-1408
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Modules
>    Affects Versions: 7.0.0.Final
>            Reporter: Sebastian Jancke
>            Assignee: Stuart Douglas
>              Labels: classloader, resteasy
>
> When using resteasy with resteasy-jackson-provider, classloading from jackson-xc to jackson-core-asl is not working because the module-dependency is missing.
> Stacktrace:
> 17:12:24,479 WARN  [org.jboss.modules] (MSC service thread 1-8) Failed to define class org.codehaus.jackson.xc.JaxbAnnotationIntrospector in Module "org.codehaus.jackson.jackson-xc:main" from local module loader @4ce66f56 (roots: OBFUSCATED\jboss-as-7.0.0.Final\modules): java.lang.LinkageError: Failed
>  to link org/codehaus/jackson/xc/JaxbAnnotationIntrospector (Module "org.codehaus.jackson.jackson-xc:main" from local module loader @4ce66f56 (roots:
>  OBFUSCATED\jboss-as-7.0.0.Final\modules))
>         at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:401)
>         at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261)
>         at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76)
>         at org.jboss.modules.Module.loadModuleClass(Module.java:588)
>         at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:183)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
>         at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
>         at java.lang.Class.getDeclaredFields0(Native Method) [:1.6.0_24]
>         at java.lang.Class.privateGetDeclaredFields(Class.java:2291) [:1.6.0_24]
>         at java.lang.Class.getDeclaredFields(Class.java:1743) [:1.6.0_24]
>         at org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:116) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at org.jboss.weld.util.reflection.SecureReflections$4.work(SecureReflections.java:112) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at org.jboss.weld.util.reflection.SecureReflectionAccess.runAndWrap(SecureReflectionAccess.java:67) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at org.jboss.weld.util.reflection.SecureReflections.getDeclaredFields(SecureReflections.java:111) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at org.jboss.weld.introspector.jlr.WeldClassImpl.<init>(WeldClassImpl.java:163) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at org.jboss.weld.introspector.jlr.WeldClassImpl.of(WeldClassImpl.java:124) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:54) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at org.jboss.weld.resources.ClassTransformer$TransformTypeToWeldClass.apply(ClassTransformer.java:42) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at com.google.common.collect.ComputingConcurrentHashMap.compute(ComputingConcurrentHashMap.java:206) [guava-r07.jar:]
>         at com.google.common.collect.ComputingConcurrentHashMap.apply(ComputingConcurrentHashMap.java:100) [guava-r07.jar:]
>         at com.google.common.collect.MapMaker$ComputingMapAdapter.get(MapMaker.java:515) [guava-r07.jar:]
>         at org.jboss.weld.resources.ClassTransformer.loadClass(ClassTransformer.java:183) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:96) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:133) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:191) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:368) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
>         at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:81) [jboss-as-weld-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.as.weld.services.WeldService.start(WeldService.java:89) [jboss-as-weld-7.0.0.Final.jar:7.0.0.Final]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
>         at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
>         at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
> Caused by: java.lang.NoClassDefFoundError: org/codehaus/jackson/Versioned
>         at java.lang.ClassLoader.defineClass1(Native Method) [:1.6.0_24]
>         at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) [:1.6.0_24]
>         at java.lang.ClassLoader.defineClass(ClassLoader.java:616) [:1.6.0_24]
>         at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) [:1.6.0_24]
>         at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:397)
>         ... 35 more
> Caused by: java.lang.ClassNotFoundException: org.codehaus.jackson.Versioned from [Module "org.codehaus.jackson.jackson-xc:main" from local module loader @4ce66f56 (roots: OBFUSCATED\jboss-as-7.0.0.Final\modules)]
>         at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
>         at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
>         ... 40 more
> FIX [module org.codehaus.jackson.jackson-xc]
> <module xmlns="urn:jboss:module:1.0" name="org.codehaus.jackson.jackson-xc">
>   <resources>
>     <resource-root path="jackson-xc-1.6.3.jar"/>
>         <!-- Insert resources here -->
>   </resources>
>   <dependencies>
>       <module name="javax.api" />
>       <module name="javax.activation.api" />
>       <module name="javax.xml.bind.api" />
>       <module name="org.codehaus.jackson.jackson-mapper-asl" />
>       <module name="org.codehaus.jackson.jackson-core-asl" />
>   </dependencies>
> </module>

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 22:04:23 2011
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Wed, 27 Jul 2011 22:04:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1350) Add management
 operations to assign/unassign handlers from loggers and async handlers.
In-Reply-To: <788349166.68808.1311164783691.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1599029105.87307.1311818663688.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617179#comment-12617179 ] 

Stan Silvert commented on AS7-1350:
-----------------------------------

That's an easy change.  Just need to rename the commands.  

But for root logger, it does make things very confusing.  If you are at subsystem=logging, this is how it would look from CLI:

[standalone at localhost:9999 subsystem=logging] :read-resource
{
    "outcome" => "success",
    "result" => {
        "async-handler" => undefined,
        "file-handler" => undefined,
        "root-logger" => {
            "level" => "INFO",
            "handlers" => [
                "CONSOLE",
                "FILE"
            ]
        },
        "size-rotating-file-handler" => undefined,
        "console-handler" => {"CONSOLE" => undefined},
        "logger" => {
            "com.arjuna" => undefined,
            "org.apache.tomcat.util.modeler" => undefined,
            "sun.rmi" => undefined
        },
        "periodic-rotating-file-handler" => {"FILE" => undefined}
    }
}
[standalone at localhost:9999 subsystem=logging] :

add                            change-root-log-level          read-attribute                 read-children-names            read-children-resources
read-children-types            read-operation-description     read-operation-names           read-resource                  read-resource-description
remove-root-logger             add-handler                    remove-handler                 set-root-logger                validate-address
write-attribute

So from there, it looks like "add-handler" and "remove-handler" mean you want to create or remove a handler.  But it really means assign or unassign a handler to/from the root logger.

> Add management operations to assign/unassign handlers from loggers and async handlers.
> --------------------------------------------------------------------------------------
>
>                 Key: AS7-1350
>                 URL: https://issues.jboss.org/browse/AS7-1350
>             Project: Application Server 7
>          Issue Type: Feature Request
>    Affects Versions: 7.0.0.Final
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>             Fix For: 7.1.0.Alpha1
>
>
> Proposed new management operations:
> For Async Handler:
> assign-subhandler
> unassign-subhandler
> For Root Logger:
> root-logger-assign-handler
> root-logger-unassign-handler
> For other Loggers:
> assign-handler
> unassign-handler

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 22:08:23 2011
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Wed, 27 Jul 2011 22:08:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-1350) Add
 management operations to assign/unassign handlers from loggers and async
 handlers.
In-Reply-To: <788349166.68808.1311164783691.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1984006538.87313.1311818903947.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617179#comment-12617179 ] 

Stan Silvert edited comment on AS7-1350 at 7/27/11 10:07 PM:
-------------------------------------------------------------

That's an easy change.  Just need to rename the commands.  

But for root logger, it does make things very confusing.  If you are at subsystem=logging, this is how it would look from CLI:

{noformat}[standalone at localhost:9999 subsystem=logging] :read-resource
{
    "outcome" => "success",
    "result" => {
        "async-handler" => undefined,
        "file-handler" => undefined,
        "root-logger" => {
            "level" => "INFO",
            "handlers" => [
                "CONSOLE",
                "FILE"
            ]
        },
        "size-rotating-file-handler" => undefined,
        "console-handler" => {"CONSOLE" => undefined},
        "logger" => {
            "com.arjuna" => undefined,
            "org.apache.tomcat.util.modeler" => undefined,
            "sun.rmi" => undefined
        },
        "periodic-rotating-file-handler" => {"FILE" => undefined}
    }
}
[standalone at localhost:9999 subsystem=logging] :

add                            change-root-log-level          read-attribute                 read-children-names            read-children-resources
read-children-types            read-operation-description     read-operation-names           read-resource                  read-resource-description
remove-root-logger             add-handler                    remove-handler                 set-root-logger                validate-address
write-attribute{noformat}

So from there, it looks like "add-handler" and "remove-handler" mean you want to create or remove a handler.  But it really means assign or unassign a handler to/from the root logger.

      was (Author: ssilvert):
    That's an easy change.  Just need to rename the commands.  

But for root logger, it does make things very confusing.  If you are at subsystem=logging, this is how it would look from CLI:

[standalone at localhost:9999 subsystem=logging] :read-resource
{
    "outcome" => "success",
    "result" => {
        "async-handler" => undefined,
        "file-handler" => undefined,
        "root-logger" => {
            "level" => "INFO",
            "handlers" => [
                "CONSOLE",
                "FILE"
            ]
        },
        "size-rotating-file-handler" => undefined,
        "console-handler" => {"CONSOLE" => undefined},
        "logger" => {
            "com.arjuna" => undefined,
            "org.apache.tomcat.util.modeler" => undefined,
            "sun.rmi" => undefined
        },
        "periodic-rotating-file-handler" => {"FILE" => undefined}
    }
}
[standalone at localhost:9999 subsystem=logging] :

add                            change-root-log-level          read-attribute                 read-children-names            read-children-resources
read-children-types            read-operation-description     read-operation-names           read-resource                  read-resource-description
remove-root-logger             add-handler                    remove-handler                 set-root-logger                validate-address
write-attribute

So from there, it looks like "add-handler" and "remove-handler" mean you want to create or remove a handler.  But it really means assign or unassign a handler to/from the root logger.
  
> Add management operations to assign/unassign handlers from loggers and async handlers.
> --------------------------------------------------------------------------------------
>
>                 Key: AS7-1350
>                 URL: https://issues.jboss.org/browse/AS7-1350
>             Project: Application Server 7
>          Issue Type: Feature Request
>    Affects Versions: 7.0.0.Final
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>             Fix For: 7.1.0.Alpha1
>
>
> Proposed new management operations:
> For Async Handler:
> assign-subhandler
> unassign-subhandler
> For Root Logger:
> root-logger-assign-handler
> root-logger-unassign-handler
> For other Loggers:
> assign-handler
> unassign-handler

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 22:08:24 2011
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Wed, 27 Jul 2011 22:08:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-1350) Add
 management operations to assign/unassign handlers from loggers and async
 handlers.
In-Reply-To: <788349166.68808.1311164783691.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1661417805.87315.1311818904015.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617179#comment-12617179 ] 

Stan Silvert edited comment on AS7-1350 at 7/27/11 10:07 PM:
-------------------------------------------------------------

That's an easy change.  Just need to rename the commands.  

But for root logger, it does make things very confusing.  If you are at subsystem=logging, this is how it would look from CLI:

{noformat}[standalone at localhost:9999 subsystem=logging] :read-resource
{
    "outcome" => "success",
    "result" => {
        "async-handler" => undefined,
        "file-handler" => undefined,
        "root-logger" => {
            "level" => "INFO",
            "handlers" => [
                "CONSOLE",
                "FILE"
            ]
        },
        "size-rotating-file-handler" => undefined,
        "console-handler" => {"CONSOLE" => undefined},
        "logger" => {
            "com.arjuna" => undefined,
            "org.apache.tomcat.util.modeler" => undefined,
            "sun.rmi" => undefined
        },
        "periodic-rotating-file-handler" => {"FILE" => undefined}
    }
}
[standalone at localhost:9999 subsystem=logging] :

add                            change-root-log-level          read-attribute                 read-children-names            read-children-resources
read-children-types            read-operation-description     read-operation-names           read-resource                  read-resource-description
remove-root-logger             add-handler                    remove-handler                 set-root-logger                validate-address
write-attribute{noformat}

(scroll down to see the rest) 

So from there, it looks like "add-handler" and "remove-handler" mean you want to create or remove a handler.  But it really means assign or unassign a handler to/from the root logger.

      was (Author: ssilvert):
    That's an easy change.  Just need to rename the commands.  

But for root logger, it does make things very confusing.  If you are at subsystem=logging, this is how it would look from CLI:

{noformat}[standalone at localhost:9999 subsystem=logging] :read-resource
{
    "outcome" => "success",
    "result" => {
        "async-handler" => undefined,
        "file-handler" => undefined,
        "root-logger" => {
            "level" => "INFO",
            "handlers" => [
                "CONSOLE",
                "FILE"
            ]
        },
        "size-rotating-file-handler" => undefined,
        "console-handler" => {"CONSOLE" => undefined},
        "logger" => {
            "com.arjuna" => undefined,
            "org.apache.tomcat.util.modeler" => undefined,
            "sun.rmi" => undefined
        },
        "periodic-rotating-file-handler" => {"FILE" => undefined}
    }
}
[standalone at localhost:9999 subsystem=logging] :

add                            change-root-log-level          read-attribute                 read-children-names            read-children-resources
read-children-types            read-operation-description     read-operation-names           read-resource                  read-resource-description
remove-root-logger             add-handler                    remove-handler                 set-root-logger                validate-address
write-attribute{noformat}

So from there, it looks like "add-handler" and "remove-handler" mean you want to create or remove a handler.  But it really means assign or unassign a handler to/from the root logger.
  
> Add management operations to assign/unassign handlers from loggers and async handlers.
> --------------------------------------------------------------------------------------
>
>                 Key: AS7-1350
>                 URL: https://issues.jboss.org/browse/AS7-1350
>             Project: Application Server 7
>          Issue Type: Feature Request
>    Affects Versions: 7.0.0.Final
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>             Fix For: 7.1.0.Alpha1
>
>
> Proposed new management operations:
> For Async Handler:
> assign-subhandler
> unassign-subhandler
> For Root Logger:
> root-logger-assign-handler
> root-logger-unassign-handler
> For other Loggers:
> assign-handler
> unassign-handler

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 22:29:23 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Wed, 27 Jul 2011 22:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1892) In failover
 on node leave mode, it needs to make sure when failover happens,
 no more messaging operations are active at the node being shutdown
Message-ID: <1828643634.87321.1311820163647.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

In failover on node leave mode, it needs to make sure when failover happens, no more messaging operations are active at the node being shutdown 
------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBMESSAGING-1892
                 URL: https://issues.jboss.org/browse/JBMESSAGING-1892
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Clustering
    Affects Versions: 1.4.8.SP2, 1.4.0.SP3.CP14
            Reporter: Yong Hao Gao
            Assignee: Yong Hao Gao
             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 22:31:23 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Wed, 27 Jul 2011 22:31:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1892) In failover
 on node leave mode, it needs to make sure when failover happens,
 no more messaging operations are active at the node being shutdown
In-Reply-To: <1828643634.87321.1311820163647.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1470251317.87325.1311820283687.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBMESSAGING-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617180#comment-12617180 ] 

Yong Hao Gao commented on JBMESSAGING-1892:
-------------------------------------------

As an example, if a message is delivered and being prepared/committed at a node being shut down, failover happens and this message may be failed over before the tx removes the ref. Thus the message may be delivered again.


> In failover on node leave mode, it needs to make sure when failover happens, no more messaging operations are active at the node being shutdown 
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1892
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1892
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP14, 1.4.8.SP2
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Wed Jul 27 23:57:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 27 Jul 2011 23:57:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1210) Messaging subsystem
 binds JMS destinations to java:
In-Reply-To: <1452571861.37545.1309963283664.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1044326638.87329.1311825443632.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved AS7-1210.
-------------------------------

    Fix Version/s: 7.0.1.Final
       Resolution: Done


> Messaging subsystem binds JMS destinations to java:
> ---------------------------------------------------
>
>                 Key: AS7-1210
>                 URL: https://issues.jboss.org/browse/AS7-1210
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 7.0.0.CR1, 7.0.0.Final
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 7.0.1.Final
>
>
> As per the discussion in this mail thread http://lists.jboss.org/pipermail/jboss-as7-dev/2011-July/002890.html:
> {quote}
> 1) Unqualified relative names like "DefaultDS" or "jdbc/DefaultDS" 
> should be qualified relative to "java:comp/env", "java:module/env", or 
> "java:jboss/env", depending on the context.
> {quote}
> So in case of JMS destinations configured in the standalone.xml/domain.xml, JNDI entries like these:
> {code:xml}
>            <jms-destinations>
>               <jms-queue name="testQueue">
>                  <entry name="queue/test"/>
>               </jms-queue>
>               <jms-topic name="testTopic">
>                  <entry name="topic/test"/>
>               </jms-topic>
>            </jms-destinations>
> {code}
> should bind under java:jboss/ namespace. 
> Instead, currently the org.jboss.as.messaging.jms.AS7BindingRegistry binds it to java: namespace.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 00:11:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 28 Jul 2011 00:11:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1358) UserTransaction not
 available to non-EE threads
In-Reply-To: <15939283.70650.1311197423915.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1171120829.87335.1311826283796.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved AS7-1358.
-------------------------------

    Fix Version/s: 7.0.1.Final
       Resolution: Done


This was pulled upstream https://source.jboss.org/changelog/JBossAS?cs=919c16e27cff2ad2046f11f17bdb99e442208abe. Marking as resolved.


> UserTransaction not available to non-EE threads
> -----------------------------------------------
>
>                 Key: AS7-1358
>                 URL: https://issues.jboss.org/browse/AS7-1358
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Transactions
>    Affects Versions: 7.0.0.Final
>            Reporter: Chris Lowe
>            Assignee: Jonathan Halliday
>             Fix For: 7.0.1.Final
>
>
> JBoss Seam offers Asynchronous behaviour for non-EJB environments using a Quartz dispatcher. Asynchronous behaviour may also make use of Seam's @Transactional marker to demarcate tx boundaries.
> Since testing one of our applications in AS7 I noticed Seam "could not discover transaction status" error messages reported as our application ran async sections of code.
> Examining the Seam code, I could see that Seam would make two attempts to access a JNDI UserTransaction resource:
> 1 - context.lookup("java:comp/UserTransaction");
> If an NameNotFoundException is thrown, then attempt:
> 2 - context.lookup("UserTransaction");
> Under AS6 and below, the latter attempt would succeed.  Under AS7 attempts are currently failing.
> While looking into this issue I came across the following developer discussion which suggests that it might be possible to add a "java:/jboss/UserTransaction" resource:
> http://lists.jboss.org/pipermail/jboss-as7-dev/2011-June/002298.html
> Further discussion on my AS7 user forum thread lead to the suggestion that I myself might add this behaviour.
> I have followed the implementation hints and light testing has been successful (with appropriate mods to Seam to use the new resource name).  I aim to perform some more thorough testing on this shortly and submit a patch against this issue.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 01:03:24 2011
From: jira-events at lists.jboss.org (Lincoln Baxter III (JIRA))
Date: Thu, 28 Jul 2011 01:03:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-708) Ability to specify
 classloading exceptions to ignore similar to
 scanning-deployers-jboss-beans.xml
In-Reply-To: <76119589.26581.1304391198359.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2113187648.87410.1311829404101.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617185#comment-12617185 ] 

Lincoln Baxter III commented on AS7-708:
----------------------------------------

I agree with this course of action. Halting deployment is almost always a bad idea!

> Ability to specify classloading exceptions to ignore similar to scanning-deployers-jboss-beans.xml
> --------------------------------------------------------------------------------------------------
>
>                 Key: AS7-708
>                 URL: https://issues.jboss.org/browse/AS7-708
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: Jason Porter
>            Assignee: David Lloyd
>         Attachments: catch-demo.war
>
>
> We need to be able to specify exceptions to ignore during classpath scanning. This was available in AS6, we need it in AS7, or something similar. Please see https://issues.jboss.org/browse/SEAMFORGE-156

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 01:17:32 2011
From: jira-events at lists.jboss.org (Wolfgang Laun (JIRA))
Date: Thu, 28 Jul 2011 01:17:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3147) Regression: all
 uppercase field reference results in compile error
In-Reply-To: <2362491.70386.1311184103681.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <97987245.87423.1311830252317.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617187#comment-12617187 ] 

Wolfgang Laun commented on JBRULES-3147:
----------------------------------------

It seems that only constraints with '||' (and thus also 'in') are affected.
 

> Regression: all uppercase field reference results in compile error
> ------------------------------------------------------------------
>
>                 Key: JBRULES-3147
>                 URL: https://issues.jboss.org/browse/JBRULES-3147
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler (expert)
>    Affects Versions: 5.2.0.Final
>            Reporter: Wolfgang Laun
>            Assignee: Mark Proctor
>             Fix For: 5.2.1.Final
>
>
> Consider the following ways of writing getters, setters and pattern field names 
>   element  xetter    field  5.1.1   5.3.0
> =============================================
>   state    xetstate  state    OK     OK
>   state    xetState  state    OK     OK
>   staTe    xetStaTe  staTe    OK     OK
>   state    xetSTATE  STATE    OK     ERR
> The last variation is a regression from 5.1.1. It is not so absurd - if the field is designated with an acronym (XML,...) this would be the natural way to write xetters and the pattern field.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 02:32:24 2011
From: jira-events at lists.jboss.org (Jean-Frederic Clere (JIRA))
Date: Thu, 28 Jul 2011 02:32:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-8297) Weld throws error
 No active contexts for scope type javax.enterprise.context.RequestScoped
Message-ID: <227898945.87488.1311834744245.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBAS-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617190#comment-12617190 ] 

Jean-Frederic Clere commented on JBAS-8297:
-------------------------------------------

It is fixed in jbossweb for AS6 (r1789 = need a new release of jbossweb-3.0.x) for AS7 (r1590 = since first version)

> Weld throws error No active contexts for scope type javax.enterprise.context.RequestScoped
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-8297
>                 URL: https://issues.jboss.org/browse/JBAS-8297
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>          Components: Weld/CDI
>         Environment: JBoss 6.0.0.M2, Windows XP SP3
>            Reporter: Marcos Antonio
>            Assignee: Remy Maucherat
>             Fix For: 6.1.0
>
>         Attachments: solicitacoes.zip
>
>
> 2010-04-22 09:55:36,484 WARN  [org.apache.catalina.authenticator.FormAuthenticator] (http-127.0.0.1-8080-1) Unexpected error forwarding to login page: javax.servlet.ServletException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 03:29:23 2011
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 28 Jul 2011 03:29:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1101) Parser error when
 processing security-identity/description ejb-jar.xml element
In-Reply-To: <2019011463.16168.1308837023750.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1199230712.87585.1311838163776.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka resolved AS7-1101.
---------------------------------

    Resolution: Done


> Parser error when processing security-identity/description ejb-jar.xml element
> ------------------------------------------------------------------------------
>
>                 Key: AS7-1101
>                 URL: https://issues.jboss.org/browse/AS7-1101
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For: 7.1.0.Alpha1
>
>
> According to ejb-jar_3_1.xsd 'description' element is optional under 'security-identity' element.
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[12,9]
> Message: Unexpected element '{http://java.sun.com/xml/ns/javaee}description' encountered
> 	at org.jboss.metadata.parser.util.MetaDataElementParser.unexpectedElement(MetaDataElementParser.java:109)
> 	at org.jboss.metadata.ejb.parser.spec.SecurityIdentityParser.processElement(SecurityIdentityParser.java:46)
> 	at org.jboss.metadata.ejb.parser.spec.SecurityIdentityParser.processElement(SecurityIdentityParser.java:16)
> 	at org.jboss.metadata.ejb.parser.spec.AbstractMetaDataParser.processElements(AbstractMetaDataParser.java:65)
> 	at org.jboss.metadata.ejb.parser.spec.SecurityIdentityParser.parse(SecurityIdentityParser.java:24)
> 	at org.jboss.metadata.ejb.parser.spec.SessionBeanMetaDataParser.processElement(SessionBeanMetaDataParser.java:224)
> 	at org.jboss.metadata.ejb.parser.spec.SessionBean30MetaDataParser.processElement(SessionBean30MetaDataParser.java:126)
> 	at org.jboss.metadata.ejb.parser.spec.SessionBean30MetaDataParser.processElement(SessionBean30MetaDataParser.java:47)
> 	at org.jboss.metadata.ejb.parser.spec.AbstractMetaDataParser.processElements(AbstractMetaDataParser.java:65)
> 	at org.jboss.metadata.ejb.parser.spec.SessionBeanMetaDataParser.parse(SessionBeanMetaDataParser.java:76)
> 	at org.jboss.metadata.ejb.parser.spec.EnterpriseBeansMetaDataParser.parse(EnterpriseBeansMetaDataParser.java:62)
> 	at org.jboss.metadata.ejb.parser.spec.EjbJarMetaDataParser.parseEjbJarElements(EjbJarMetaDataParser.java:274)
> 	at org.jboss.metadata.ejb.parser.spec.EjbJarMetaDataParser.parse(EjbJarMetaDataParser.java:142)
> 	at org.jboss.as.ejb3.deployment.processors.EjbJarParsingDeploymentUnitProcessor.deploy(EjbJarParsingDeploymentUnitProcessor.java:143)
> 	... 6 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 03:31:23 2011
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 28 Jul 2011 03:31:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1125) Implement
 service-ref/wsdl-override parsing
Message-ID: <108306053.87595.1311838283988.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka resolved AS7-1125.
---------------------------------

    Resolution: Done


> Implement service-ref/wsdl-override parsing
> -------------------------------------------
>
>                 Key: AS7-1125
>                 URL: https://issues.jboss.org/browse/AS7-1125
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For: 7.1.0.Alpha1
>
>
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[22,5]
> Message: Unexpected element 'wsdl-override' encountered
> 	at org.jboss.metadata.parser.util.MetaDataElementParser.unexpectedElement(MetaDataElementParser.java:109)
> 	at org.jboss.metadata.parser.ee.ServiceReferenceMetaDataParser.parse(ServiceReferenceMetaDataParser.java:127)
> 	at org.jboss.metadata.parser.ee.EnvironmentRefsGroupMetaDataParser.parse(EnvironmentRefsGroupMetaDataParser.java:81)
> 	at org.jboss.metadata.parser.jbossweb.JBossWebMetaDataParser.parse(JBossWebMetaDataParser.java:108)
> 	at org.jboss.as.web.deployment.JBossWebParsingDeploymentProcessor.deploy(JBossWebParsingDeploymentProcessor.java:64)
> 	... 6 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 03:43:23 2011
From: jira-events at lists.jboss.org (wiktorowski maximilien (JIRA))
Date: Thu, 28 Jul 2011 03:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1423) Servlet mark as
 asynchrone in web.xml throws IllegalStateException when calling startAsync
Message-ID: <197642012.87630.1311839003705.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Servlet mark as asynchrone in web.xml throws IllegalStateException when calling startAsync
------------------------------------------------------------------------------------------

                 Key: AS7-1423
                 URL: https://issues.jboss.org/browse/AS7-1423
             Project: Application Server 7
          Issue Type: Bug
    Affects Versions: 7.0.0.Final
            Reporter: wiktorowski maximilien


I noticed the problem when i put seam-solder in my ear/lib folder.
Then if i mark my servlet as asynchrone in web.xml:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">
	<display-name>Mpulse test Servlet 3.0</display-name>
	
	<servlet>
		<servlet-name>MyServlet</servlet-name>
		<servlet-class>eu.mpulse.test.MyServlet</servlet-class>
		<async-supported>true</async-supported>
	</servlet>

	<servlet-mapping>
		<servlet-name>MyServlet</servlet-name>
		<url-pattern>/servletgrrr/hello</url-pattern>
	</servlet-mapping>
</web-app>

a call to startAsync on the servlet throws:
"java.lang.IllegalStateException: The servlet or filters that are being used by this request do not support async operation"


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 03:45:23 2011
From: jira-events at lists.jboss.org (wiktorowski maximilien (JIRA))
Date: Thu, 28 Jul 2011 03:45:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1423) Servlet mark as
 asynchrone in web.xml throws IllegalStateException when calling startAsync
In-Reply-To: <197642012.87630.1311839003705.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1669508298.87635.1311839123935.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

wiktorowski maximilien updated AS7-1423:
----------------------------------------

    Attachment: ear.ear


> Servlet mark as asynchrone in web.xml throws IllegalStateException when calling startAsync
> ------------------------------------------------------------------------------------------
>
>                 Key: AS7-1423
>                 URL: https://issues.jboss.org/browse/AS7-1423
>             Project: Application Server 7
>          Issue Type: Bug
>    Affects Versions: 7.0.0.Final
>            Reporter: wiktorowski maximilien
>         Attachments: ear.ear
>
>
> I noticed the problem when i put seam-solder in my ear/lib folder.
> Then if i mark my servlet as asynchrone in web.xml:
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">
> 	<display-name>Mpulse test Servlet 3.0</display-name>
> 	
> 	<servlet>
> 		<servlet-name>MyServlet</servlet-name>
> 		<servlet-class>eu.mpulse.test.MyServlet</servlet-class>
> 		<async-supported>true</async-supported>
> 	</servlet>
> 	<servlet-mapping>
> 		<servlet-name>MyServlet</servlet-name>
> 		<url-pattern>/servletgrrr/hello</url-pattern>
> 	</servlet-mapping>
> </web-app>
> a call to startAsync on the servlet throws:
> "java.lang.IllegalStateException: The servlet or filters that are being used by this request do not support async operation"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 03:47:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 28 Jul 2011 03:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1423) Servlet mark as
 asynchrone in web.xml throws IllegalStateException when calling startAsync
In-Reply-To: <197642012.87630.1311839003705.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1010585211.87638.1311839243717.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated AS7-1423:
------------------------------

           Assignee: Remy Maucherat
        Component/s: Web
    Forum Reference: http://community.jboss.org/thread/170070  (was: http://community.jboss.org/thread/170070)


> Servlet mark as asynchrone in web.xml throws IllegalStateException when calling startAsync
> ------------------------------------------------------------------------------------------
>
>                 Key: AS7-1423
>                 URL: https://issues.jboss.org/browse/AS7-1423
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>            Reporter: wiktorowski maximilien
>            Assignee: Remy Maucherat
>         Attachments: ear.ear
>
>
> I noticed the problem when i put seam-solder in my ear/lib folder.
> Then if i mark my servlet as asynchrone in web.xml:
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">
> 	<display-name>Mpulse test Servlet 3.0</display-name>
> 	
> 	<servlet>
> 		<servlet-name>MyServlet</servlet-name>
> 		<servlet-class>eu.mpulse.test.MyServlet</servlet-class>
> 		<async-supported>true</async-supported>
> 	</servlet>
> 	<servlet-mapping>
> 		<servlet-name>MyServlet</servlet-name>
> 		<url-pattern>/servletgrrr/hello</url-pattern>
> 	</servlet-mapping>
> </web-app>
> a call to startAsync on the servlet throws:
> "java.lang.IllegalStateException: The servlet or filters that are being used by this request do not support async operation"

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 04:38:25 2011
From: jira-events at lists.jboss.org (Jordi Alvarez (JIRA))
Date: Thu, 28 Jul 2011 04:38:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2453) Marshalling
 issue with not rules
In-Reply-To: <1869982831.1268694157678.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1997207728.87776.1311842305356.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-2453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617214#comment-12617214 ] 

Jordi Alvarez commented on JBRULES-2453:
----------------------------------------

Just for completeness:

This problem was not specific to not nodes but also to exist nodes.

We are using version 5.1.1. In our situation, the write of the rete tree state enters in a infinite loop whenever:

- An exists node is reached which is blocked and has a child.
In this situation an infinite loop occurs in method OutputMarshaller.writeInitialFactHandleLeftTuples when persisting the exists node.

The changes already applied to OutputMarshaller class in the current development version fixed the problem for our situation.



> Marshalling issue with not rules
> --------------------------------
>
>                 Key: JBRULES-2453
>                 URL: https://issues.jboss.org/browse/JBRULES-2453
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions: 5.1.0.M1, 5.1.1.FINAL
>            Reporter: Kris Verlaenen
>            Assignee: Edson Tirelli
>             Fix For: 5.3.0.Beta1
>
>
> Issue with OutputMarshaller in specific case of Not rules:
> java.lang.OutOfMemoryError: Java heap space
>         at java.util.Arrays.copyOf(Arrays.java:2786)
>         at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94)
>         at
> java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1838)
>         at
> java.io.ObjectOutputStream$BlockDataOutputStream.write(ObjectOutputStream.java:1769)
>         at java.io.DataOutputStream.writeInt(DataOutputStream.java:182)
>         at
> java.io.ObjectOutputStream$BlockDataOutputStream.writeInt(ObjectOutputStream.java:1904)
>         at java.io.ObjectOutputStream.writeInt(ObjectOutputStream.java:769)
>         at
> org.drools.marshalling.impl.OutputMarshaller.writeLeftTuple(OutputMarshaller.java:459)
>         at
> org.drools.marshalling.impl.OutputMarshaller.writeInitialFactHandleLeftTuples(OutputMarshaller.java:356)
>         at
> org.drools.marshalling.impl.OutputMarshaller.writeFactHandles(OutputMarshaller.java:251)
>         at
> org.drools.marshalling.impl.OutputMarshaller.writeSession(OutputMarshaller.java:85)
>         at
> org.drools.marshalling.impl.DefaultMarshaller.marshall(DefaultMarshaller.java:117)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 05:20:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Thu, 28 Jul 2011 05:20:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1424) Blueprint Container
 cannot obtain SchemaFactory
Message-ID: <538250042.87831.1311844823620.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Blueprint Container cannot obtain SchemaFactory
-----------------------------------------------

                 Key: AS7-1424
                 URL: https://issues.jboss.org/browse/AS7-1424
             Project: Application Server 7
          Issue Type: Bug
          Components: OSGi
            Reporter: Thomas Diesler
            Assignee: Thomas Diesler
             Fix For: 7.1.0.Alpha1


10:46:41,387 ERROR [org.apache.aries.blueprint.container.BlueprintContainerImpl] (pool-7-thread-1) Unable to start blueprint container for bundle example-blueprint: java.lang.IllegalArgumentException: No SchemaFactory that implements the schema language specified by: http://www.w3.org/2001/XMLSchema could be loaded
	at javax.xml.validation.SchemaFactory.newInstance(SchemaFactory.java:207) [:1.6.0_26]
	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.getSchemaFactory(NamespaceHandlerRegistryImpl.java:266) [NamespaceHandlerRegistryImpl.class:]
	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.getSchema(NamespaceHandlerRegistryImpl.java:236) [NamespaceHandlerRegistryImpl.class:]
	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.getSchema(NamespaceHandlerRegistryImpl.java:306) [NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.class:]


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 05:44:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Thu, 28 Jul 2011 05:44:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1424) Blueprint Container
 cannot obtain SchemaFactory
In-Reply-To: <538250042.87831.1311844823620.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <897566970.87900.1311846263759.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617232#comment-12617232 ] 

Thomas Diesler commented on AS7-1424:
-------------------------------------

11:42:29,506 ERROR [stderr] (RMI TCP Connection(2)-127.0.0.1) JAXP: using thread context class loader (ModuleClassLoader for Module "deployment.arquillian-service:main" from Service Module Loader) for search
11:42:29,506 ERROR [stderr] (RMI TCP Connection(2)-127.0.0.1) JAXP: Looking up system property 'javax.xml.validation.SchemaFactory:http://www.w3.org/2001/XMLSchema'
11:42:29,507 ERROR [stderr] (RMI TCP Connection(2)-127.0.0.1) JAXP: The property is undefined.
11:42:29,507 ERROR [stderr] (RMI TCP Connection(2)-127.0.0.1) JAXP: found null in $java.home/jaxp.properties
11:42:29,508 ERROR [stderr] (RMI TCP Connection(2)-127.0.0.1) JAXP: no META-INF/services/javax.xml.validation.SchemaFactory file was found
11:42:29,508 ERROR [stderr] (RMI TCP Connection(2)-127.0.0.1) JAXP: attempting to use the platform default XML Schema validator
11:42:29,508 ERROR [stderr] (RMI TCP Connection(2)-127.0.0.1) JAXP: createInstance(com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory)
11:42:29,509 ERROR [stderr] (RMI TCP Connection(2)-127.0.0.1) java.lang.ClassNotFoundException: com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory from [Module "deployment.arquillian-service:main" from Service Module Loader]


> Blueprint Container cannot obtain SchemaFactory
> -----------------------------------------------
>
>                 Key: AS7-1424
>                 URL: https://issues.jboss.org/browse/AS7-1424
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: OSGi
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For: 7.1.0.Alpha1
>
>
> 10:46:41,387 ERROR [org.apache.aries.blueprint.container.BlueprintContainerImpl] (pool-7-thread-1) Unable to start blueprint container for bundle example-blueprint: java.lang.IllegalArgumentException: No SchemaFactory that implements the schema language specified by: http://www.w3.org/2001/XMLSchema could be loaded
> 	at javax.xml.validation.SchemaFactory.newInstance(SchemaFactory.java:207) [:1.6.0_26]
> 	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.getSchemaFactory(NamespaceHandlerRegistryImpl.java:266) [NamespaceHandlerRegistryImpl.class:]
> 	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.getSchema(NamespaceHandlerRegistryImpl.java:236) [NamespaceHandlerRegistryImpl.class:]
> 	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.getSchema(NamespaceHandlerRegistryImpl.java:306) [NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.class:]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 05:46:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Thu, 28 Jul 2011 05:46:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-1424)
 Blueprint Container cannot obtain SchemaFactory
In-Reply-To: <538250042.87831.1311844823620.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1341425719.87902.1311846383755.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617232#comment-12617232 ] 

Thomas Diesler edited comment on AS7-1424 at 7/28/11 5:44 AM:
--------------------------------------------------------------

{code}
11:42:29,506 ERROR [stderr] (RMI TCP Connection(2)-127.0.0.1) JAXP: using thread context class loader (ModuleClassLoader for Module "deployment.arquillian-service:main" from Service Module Loader) for search
11:42:29,506 ERROR [stderr] (RMI TCP Connection(2)-127.0.0.1) JAXP: Looking up system property 'javax.xml.validation.SchemaFactory:http://www.w3.org/2001/XMLSchema'
11:42:29,507 ERROR [stderr] (RMI TCP Connection(2)-127.0.0.1) JAXP: The property is undefined.
11:42:29,507 ERROR [stderr] (RMI TCP Connection(2)-127.0.0.1) JAXP: found null in $java.home/jaxp.properties
11:42:29,508 ERROR [stderr] (RMI TCP Connection(2)-127.0.0.1) JAXP: no META-INF/services/javax.xml.validation.SchemaFactory file was found
11:42:29,508 ERROR [stderr] (RMI TCP Connection(2)-127.0.0.1) JAXP: attempting to use the platform default XML Schema validator
11:42:29,508 ERROR [stderr] (RMI TCP Connection(2)-127.0.0.1) JAXP: createInstance(com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory)
11:42:29,509 ERROR [stderr] (RMI TCP Connection(2)-127.0.0.1) java.lang.ClassNotFoundException: com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory from [Module "deployment.arquillian-service:main" from Service Module Loader]
{code}

      was (Author: thomas.diesler):
    11:42:29,506 ERROR [stderr] (RMI TCP Connection(2)-127.0.0.1) JAXP: using thread context class loader (ModuleClassLoader for Module "deployment.arquillian-service:main" from Service Module Loader) for search
11:42:29,506 ERROR [stderr] (RMI TCP Connection(2)-127.0.0.1) JAXP: Looking up system property 'javax.xml.validation.SchemaFactory:http://www.w3.org/2001/XMLSchema'
11:42:29,507 ERROR [stderr] (RMI TCP Connection(2)-127.0.0.1) JAXP: The property is undefined.
11:42:29,507 ERROR [stderr] (RMI TCP Connection(2)-127.0.0.1) JAXP: found null in $java.home/jaxp.properties
11:42:29,508 ERROR [stderr] (RMI TCP Connection(2)-127.0.0.1) JAXP: no META-INF/services/javax.xml.validation.SchemaFactory file was found
11:42:29,508 ERROR [stderr] (RMI TCP Connection(2)-127.0.0.1) JAXP: attempting to use the platform default XML Schema validator
11:42:29,508 ERROR [stderr] (RMI TCP Connection(2)-127.0.0.1) JAXP: createInstance(com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory)
11:42:29,509 ERROR [stderr] (RMI TCP Connection(2)-127.0.0.1) java.lang.ClassNotFoundException: com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory from [Module "deployment.arquillian-service:main" from Service Module Loader]

  
> Blueprint Container cannot obtain SchemaFactory
> -----------------------------------------------
>
>                 Key: AS7-1424
>                 URL: https://issues.jboss.org/browse/AS7-1424
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: OSGi
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For: 7.1.0.Alpha1
>
>
> 10:46:41,387 ERROR [org.apache.aries.blueprint.container.BlueprintContainerImpl] (pool-7-thread-1) Unable to start blueprint container for bundle example-blueprint: java.lang.IllegalArgumentException: No SchemaFactory that implements the schema language specified by: http://www.w3.org/2001/XMLSchema could be loaded
> 	at javax.xml.validation.SchemaFactory.newInstance(SchemaFactory.java:207) [:1.6.0_26]
> 	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.getSchemaFactory(NamespaceHandlerRegistryImpl.java:266) [NamespaceHandlerRegistryImpl.class:]
> 	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.getSchema(NamespaceHandlerRegistryImpl.java:236) [NamespaceHandlerRegistryImpl.class:]
> 	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.getSchema(NamespaceHandlerRegistryImpl.java:306) [NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.class:]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 05:46:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Thu, 28 Jul 2011 05:46:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1424) Blueprint Container
 cannot obtain SchemaFactory
In-Reply-To: <538250042.87831.1311844823620.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1328064619.87904.1311846383853.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler updated AS7-1424:
--------------------------------

    Description: 
{code}
10:46:41,387 ERROR [org.apache.aries.blueprint.container.BlueprintContainerImpl] (pool-7-thread-1) Unable to start blueprint container for bundle example-blueprint: java.lang.IllegalArgumentException: No SchemaFactory that implements the schema language specified by: http://www.w3.org/2001/XMLSchema could be loaded
	at javax.xml.validation.SchemaFactory.newInstance(SchemaFactory.java:207) [:1.6.0_26]
	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.getSchemaFactory(NamespaceHandlerRegistryImpl.java:266) [NamespaceHandlerRegistryImpl.class:]
	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.getSchema(NamespaceHandlerRegistryImpl.java:236) [NamespaceHandlerRegistryImpl.class:]
	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.getSchema(NamespaceHandlerRegistryImpl.java:306) [NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.class:]
{code}

  was:
10:46:41,387 ERROR [org.apache.aries.blueprint.container.BlueprintContainerImpl] (pool-7-thread-1) Unable to start blueprint container for bundle example-blueprint: java.lang.IllegalArgumentException: No SchemaFactory that implements the schema language specified by: http://www.w3.org/2001/XMLSchema could be loaded
	at javax.xml.validation.SchemaFactory.newInstance(SchemaFactory.java:207) [:1.6.0_26]
	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.getSchemaFactory(NamespaceHandlerRegistryImpl.java:266) [NamespaceHandlerRegistryImpl.class:]
	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.getSchema(NamespaceHandlerRegistryImpl.java:236) [NamespaceHandlerRegistryImpl.class:]
	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.getSchema(NamespaceHandlerRegistryImpl.java:306) [NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.class:]




> Blueprint Container cannot obtain SchemaFactory
> -----------------------------------------------
>
>                 Key: AS7-1424
>                 URL: https://issues.jboss.org/browse/AS7-1424
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: OSGi
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For: 7.1.0.Alpha1
>
>
> {code}
> 10:46:41,387 ERROR [org.apache.aries.blueprint.container.BlueprintContainerImpl] (pool-7-thread-1) Unable to start blueprint container for bundle example-blueprint: java.lang.IllegalArgumentException: No SchemaFactory that implements the schema language specified by: http://www.w3.org/2001/XMLSchema could be loaded
> 	at javax.xml.validation.SchemaFactory.newInstance(SchemaFactory.java:207) [:1.6.0_26]
> 	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.getSchemaFactory(NamespaceHandlerRegistryImpl.java:266) [NamespaceHandlerRegistryImpl.class:]
> 	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.getSchema(NamespaceHandlerRegistryImpl.java:236) [NamespaceHandlerRegistryImpl.class:]
> 	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.getSchema(NamespaceHandlerRegistryImpl.java:306) [NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.class:]
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 05:46:23 2011
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 28 Jul 2011 05:46:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1407) JNDI view operation
 doesn't show all entries
In-Reply-To: <1759022158.82897.1311694223635.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1605530182.87908.1311846383948.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617233#comment-12617233 ] 

Richard Opalka commented on AS7-1407:
-------------------------------------

There's another issue with our Naming store :(
I have the following piece of code in our web.xml DD:
---
<env-entry>
  <env-entry-name>jaxws/entry1</env-entry-name>
  <env-entry-type>java.lang.String</env-entry-type>
  <env-entry-value>web</env-entry-value>
  <injection-target>
    <injection-target-class>org.jboss.test.ws.jaxws.enventry.EnvEntryBeanJSE</injection-target-class>
    <injection-target-name>strValue</injection-target-name>
  </injection-target>
</env-entry>
 
<env-entry>
  <env-entry-name>jaxws/entry2</env-entry-name>
  <env-entry-type>java.lang.Integer</env-entry-type>
  <env-entry-value>8</env-entry-value>
</env-entry>
---
This results in the following output in the CLI:
---
            "jaxws-enventry-jse.war" => {
                "java:app" => {"AppName" => {
                    "class-name" => "org.jboss.as.naming.context.ModularReference",
                    "value" => "jaxws-enventry-jse"
                }},
                "modules" => {"jaxws-enventry-jse" => {"java:module" => {
                    "Validator" => {
                        "class-name" => "org.jboss.as.naming.context.ModularReference",
                        "value" => "org.hibernate.validator.engine.ValidatorImpl at c2e42fe"
                    },
                    "ValidatorFactory" => {
                        "class-name" => "org.jboss.as.naming.context.ModularReference",
                        "value" => "org.jboss.as.ee.beanvalidation.LazyValidatorFactory at 54a8c871"
                    },
                    "UserTransaction" => {
                        "class-name" => "org.jboss.as.naming.context.ModularReference",
                        "value" => "Transaction: unknown"
                    },
                    "ModuleName" => {
                        "class-name" => "org.jboss.as.naming.context.ModularReference",
                        "value" => "jaxws-enventry-jse"
                    },
                    "env" => {
                        "class-name" => "javax.naming.Context",
                        "children" => {
                            "entry1" => {
                                "class-name" => "org.jboss.as.naming.context.ModularReference",
                                "value" => "web"
                            },
                            "entry2" => {
                                "class-name" => "org.jboss.as.naming.context.ModularReference",
                                "value" => "8"
                            }
                        }
                    },
                    "TransactionSynchronizationRegistry" => {
                        "class-name" => "org.jboss.as.naming.context.ModularReference",
                        "value" => "com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionSynchronizationRegistryImple at 3ff9ddb5"
                    }
                }}}
            }
---

Note the missing 'jaxws' prefix?

And at the end when I was debugging our JNDI naming store, I noticed
that missing 'jaxws' context is present in the debugger.
It's just not displayed.

Another thing that I noticed is when I'm doing the following lookup:
---
new InitialContext().lookup(POJO_JNDI_PREFIX);
---
then for above web.xml DD configuration "env/jaxws" is returned
instead of expected "env/" context :(


> JNDI view operation doesn't show all entries
> --------------------------------------------
>
>                 Key: AS7-1407
>                 URL: https://issues.jboss.org/browse/AS7-1407
>             Project: Application Server 7
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: John Bailey
>
> don't ask me why, but a queue (java:/jboss/queues/myQueue) for instance is not shown. Same thing for resource adapter, etc.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 05:48:24 2011
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 28 Jul 2011 05:48:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-1407) JNDI
 view operation doesn't show all entries
In-Reply-To: <1759022158.82897.1311694223635.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1118420815.87920.1311846504122.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617233#comment-12617233 ] 

Richard Opalka edited comment on AS7-1407 at 7/28/11 5:47 AM:
--------------------------------------------------------------

There's another issue with our Naming store :(
I have the following piece of code in our web.xml DD:
---
<env-entry>
  <env-entry-name>jaxws/entry1</env-entry-name>
  <env-entry-type>java.lang.String</env-entry-type>
  <env-entry-value>web</env-entry-value>
  <injection-target>
    <injection-target-class>org.jboss.test.ws.jaxws.enventry.EnvEntryBeanJSE</injection-target-class>
    <injection-target-name>strValue</injection-target-name>
  </injection-target>
</env-entry>
 
<env-entry>
  <env-entry-name>jaxws/entry2</env-entry-name>
  <env-entry-type>java.lang.Integer</env-entry-type>
  <env-entry-value>8</env-entry-value>
</env-entry>
---
This results in the following output in the CLI:
---
            ...
            "jaxws-enventry-jse.war" => {
                "modules" => {"jaxws-enventry-jse" => {"java:module" => {
                    ...
                    "env" => {
                        "class-name" => "javax.naming.Context",
                        "children" => {
                            "entry1" => {
                                "class-name" => "org.jboss.as.naming.context.ModularReference",
                                "value" => "web"
                            },
                            "entry2" => {
                                "class-name" => "org.jboss.as.naming.context.ModularReference",
                                "value" => "8"
                            }
                        }
                    },
                }}}
            }
            ...
---

Note the missing 'jaxws' prefix?

And at the end when I was debugging our JNDI naming store, I noticed
that missing 'jaxws' context is present in the debugger.
It's just not displayed.

Another thing that I noticed is when I'm doing the following lookup:
---
new InitialContext().lookup(POJO_JNDI_PREFIX);
---
then for above web.xml DD configuration "env/jaxws" is returned
instead of expected "env/" context :(


      was (Author: ropalka):
    There's another issue with our Naming store :(
I have the following piece of code in our web.xml DD:
---
<env-entry>
  <env-entry-name>jaxws/entry1</env-entry-name>
  <env-entry-type>java.lang.String</env-entry-type>
  <env-entry-value>web</env-entry-value>
  <injection-target>
    <injection-target-class>org.jboss.test.ws.jaxws.enventry.EnvEntryBeanJSE</injection-target-class>
    <injection-target-name>strValue</injection-target-name>
  </injection-target>
</env-entry>
 
<env-entry>
  <env-entry-name>jaxws/entry2</env-entry-name>
  <env-entry-type>java.lang.Integer</env-entry-type>
  <env-entry-value>8</env-entry-value>
</env-entry>
---
This results in the following output in the CLI:
---
            "jaxws-enventry-jse.war" => {
                "java:app" => {"AppName" => {
                    "class-name" => "org.jboss.as.naming.context.ModularReference",
                    "value" => "jaxws-enventry-jse"
                }},
                "modules" => {"jaxws-enventry-jse" => {"java:module" => {
                    "Validator" => {
                        "class-name" => "org.jboss.as.naming.context.ModularReference",
                        "value" => "org.hibernate.validator.engine.ValidatorImpl at c2e42fe"
                    },
                    "ValidatorFactory" => {
                        "class-name" => "org.jboss.as.naming.context.ModularReference",
                        "value" => "org.jboss.as.ee.beanvalidation.LazyValidatorFactory at 54a8c871"
                    },
                    "UserTransaction" => {
                        "class-name" => "org.jboss.as.naming.context.ModularReference",
                        "value" => "Transaction: unknown"
                    },
                    "ModuleName" => {
                        "class-name" => "org.jboss.as.naming.context.ModularReference",
                        "value" => "jaxws-enventry-jse"
                    },
                    "env" => {
                        "class-name" => "javax.naming.Context",
                        "children" => {
                            "entry1" => {
                                "class-name" => "org.jboss.as.naming.context.ModularReference",
                                "value" => "web"
                            },
                            "entry2" => {
                                "class-name" => "org.jboss.as.naming.context.ModularReference",
                                "value" => "8"
                            }
                        }
                    },
                    "TransactionSynchronizationRegistry" => {
                        "class-name" => "org.jboss.as.naming.context.ModularReference",
                        "value" => "com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionSynchronizationRegistryImple at 3ff9ddb5"
                    }
                }}}
            }
---

Note the missing 'jaxws' prefix?

And at the end when I was debugging our JNDI naming store, I noticed
that missing 'jaxws' context is present in the debugger.
It's just not displayed.

Another thing that I noticed is when I'm doing the following lookup:
---
new InitialContext().lookup(POJO_JNDI_PREFIX);
---
then for above web.xml DD configuration "env/jaxws" is returned
instead of expected "env/" context :(

  
> JNDI view operation doesn't show all entries
> --------------------------------------------
>
>                 Key: AS7-1407
>                 URL: https://issues.jboss.org/browse/AS7-1407
>             Project: Application Server 7
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: John Bailey
>
> don't ask me why, but a queue (java:/jboss/queues/myQueue) for instance is not shown. Same thing for resource adapter, etc.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 05:48:24 2011
From: jira-events at lists.jboss.org (Richard Opalka (JIRA))
Date: Thu, 28 Jul 2011 05:48:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-1407) JNDI
 view operation doesn't show all entries
In-Reply-To: <1759022158.82897.1311694223635.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <252160149.87931.1311846504553.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617233#comment-12617233 ] 

Richard Opalka edited comment on AS7-1407 at 7/28/11 5:48 AM:
--------------------------------------------------------------

There's another issue with our Naming store :(
I have the following piece of code in our web.xml DD:
---
<env-entry>
  <env-entry-name>jaxws/entry1</env-entry-name>
  <env-entry-type>java.lang.String</env-entry-type>
  <env-entry-value>web</env-entry-value>
  <injection-target>
    <injection-target-class>org.jboss.test.ws.jaxws.enventry.EnvEntryBeanJSE</injection-target-class>
    <injection-target-name>strValue</injection-target-name>
  </injection-target>
</env-entry>
 
<env-entry>
  <env-entry-name>jaxws/entry2</env-entry-name>
  <env-entry-type>java.lang.Integer</env-entry-type>
  <env-entry-value>8</env-entry-value>
</env-entry>
---
This results in the following output in the CLI:
---
            ...
            "jaxws-enventry-jse.war" => {
                "modules" => {"jaxws-enventry-jse" => {"java:module" => {
                    ...
                    "env" => {
                        "class-name" => "javax.naming.Context",
                        "children" => {
                            "entry1" => {
                                "class-name" => "org.jboss.as.naming.context.ModularReference",
                                "value" => "web"
                            },
                            "entry2" => {
                                "class-name" => "org.jboss.as.naming.context.ModularReference",
                                "value" => "8"
                            }
                        }
                    },
                }}}
            }
            ...
---

Note the missing 'jaxws' prefix?

And at the end when I was debugging our JNDI naming store, I noticed
that missing 'jaxws' context is present in the debugger.
It's just not displayed.

Another thing that I noticed is when I'm doing the following lookup:
---
new InitialContext().lookup("java:comp/env/");
---
then for above web.xml DD configuration "env/jaxws" is returned
instead of expected "env/" context :(


      was (Author: ropalka):
    There's another issue with our Naming store :(
I have the following piece of code in our web.xml DD:
---
<env-entry>
  <env-entry-name>jaxws/entry1</env-entry-name>
  <env-entry-type>java.lang.String</env-entry-type>
  <env-entry-value>web</env-entry-value>
  <injection-target>
    <injection-target-class>org.jboss.test.ws.jaxws.enventry.EnvEntryBeanJSE</injection-target-class>
    <injection-target-name>strValue</injection-target-name>
  </injection-target>
</env-entry>
 
<env-entry>
  <env-entry-name>jaxws/entry2</env-entry-name>
  <env-entry-type>java.lang.Integer</env-entry-type>
  <env-entry-value>8</env-entry-value>
</env-entry>
---
This results in the following output in the CLI:
---
            ...
            "jaxws-enventry-jse.war" => {
                "modules" => {"jaxws-enventry-jse" => {"java:module" => {
                    ...
                    "env" => {
                        "class-name" => "javax.naming.Context",
                        "children" => {
                            "entry1" => {
                                "class-name" => "org.jboss.as.naming.context.ModularReference",
                                "value" => "web"
                            },
                            "entry2" => {
                                "class-name" => "org.jboss.as.naming.context.ModularReference",
                                "value" => "8"
                            }
                        }
                    },
                }}}
            }
            ...
---

Note the missing 'jaxws' prefix?

And at the end when I was debugging our JNDI naming store, I noticed
that missing 'jaxws' context is present in the debugger.
It's just not displayed.

Another thing that I noticed is when I'm doing the following lookup:
---
new InitialContext().lookup(POJO_JNDI_PREFIX);
---
then for above web.xml DD configuration "env/jaxws" is returned
instead of expected "env/" context :(

  
> JNDI view operation doesn't show all entries
> --------------------------------------------
>
>                 Key: AS7-1407
>                 URL: https://issues.jboss.org/browse/AS7-1407
>             Project: Application Server 7
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: John Bailey
>
> don't ask me why, but a queue (java:/jboss/queues/myQueue) for instance is not shown. Same thing for resource adapter, etc.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 06:50:24 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Thu, 28 Jul 2011 06:50:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-951)
 :installed-drivers-list should not be enabled for subsystem=datasource in
 domain mode
In-Reply-To: <181860081.8766.1307452559689.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1474101774.87996.1311850224124.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Rupp updated AS7-951:
---------------------------

    Priority: Minor  (was: Major)


> :installed-drivers-list should not be enabled for subsystem=datasource in domain mode
> -------------------------------------------------------------------------------------
>
>                 Key: AS7-951
>                 URL: https://issues.jboss.org/browse/AS7-951
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Rupp
>            Priority: Minor
>
> [15:05:42] <+pilhuhn> [domain at localhost:9999 subsystem=datasources] :installed-drivers-list
> [15:05:42] <+pilhuhn> {
> [15:05:42] <+pilhuhn>    "outcome" => "success",
> [15:05:42] <+pilhuhn>    "result" => undefined,
> [15:05:56] <+pilhuhn> Or is that a domain vs standalone thing again? Let me check that
> [15:06:20] <hbraun> in domain mode this needs to executed against a host
> [15:07:01] <+pilhuhn> hm. Does that make sense?
> [15:07:23] <hbraun> yes, the drives can be installed as deployments
> [15:07:34] <hbraun> which is a host thing
> [15:08:34] <+pilhuhn> not server-group?
> [15:08:52] <hbraun> no, host
> [15:09:02] <+pilhuhn> And then I would expect that the /profile=x/subysy=ds/ would not support :installed-driver-list
> [15:09:02] <hbraun> the host installes it as a runtime component
> [15:09:15] <hbraun> yes, that's right
> [15:09:22] <hbraun> it shouldn't

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 06:52:23 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Thu, 28 Jul 2011 06:52:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-950) Bad description for
 subsystem=datasources:installed-drivers-list
In-Reply-To: <128272751.8745.1307451839566.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2094656413.87999.1311850343768.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Rupp resolved AS7-950.
----------------------------

    Fix Version/s: 7.0.0.Final
       Resolution: Done


> Bad description for subsystem=datasources:installed-drivers-list
> ----------------------------------------------------------------
>
>                 Key: AS7-950
>                 URL: https://issues.jboss.org/browse/AS7-950
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Rupp
>             Fix For: 7.0.0.Final
>
>
> [domain at localhost:9999 subsystem=datasources] :read-operation-description(name=installed-drivers-list)
> {
>     "outcome" => "success",
>     "result" => {
>         "operation-name" => "installed-driver-list",
>         "description" => "Adds the data-sources subsystem. ",
>         "request-properties" => {},
>         "reply-properties" => {"attributes" => {

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 07:12:23 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 28 Jul 2011 07:12:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMESSAGING-1892) In failover
 on node leave mode, it needs to make sure when failover happens,
 no more messaging operations are active at the node being shutdown
In-Reply-To: <1828643634.87321.1311820163647.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1485147549.88030.1311851543714.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao resolved JBMESSAGING-1892.
---------------------------------------

    Resolution: Done


manually tested.

> In failover on node leave mode, it needs to make sure when failover happens, no more messaging operations are active at the node being shutdown 
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1892
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1892
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP14, 1.4.8.SP2
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 07:14:23 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 28 Jul 2011 07:14:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1892) In failover on
 node leave mode, it needs to make sure when failover happens,
 no more messaging operations are active at the node being shutdown
In-Reply-To: <1828643634.87321.1311820163647.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1670431344.88034.1311851663825.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao closed JBMESSAGING-1892.
-------------------------------------



> In failover on node leave mode, it needs to make sure when failover happens, no more messaging operations are active at the node being shutdown 
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1892
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1892
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP14, 1.4.8.SP2
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 07:18:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Thu, 28 Jul 2011 07:18:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1424) Blueprint Container
 cannot obtain SchemaFactory
In-Reply-To: <538250042.87831.1311844823620.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1352247271.88036.1311851903617.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler resolved AS7-1424.
---------------------------------

    Resolution: Done


Done

> Blueprint Container cannot obtain SchemaFactory
> -----------------------------------------------
>
>                 Key: AS7-1424
>                 URL: https://issues.jboss.org/browse/AS7-1424
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: OSGi
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For: 7.1.0.Alpha1
>
>
> {code}
> 10:46:41,387 ERROR [org.apache.aries.blueprint.container.BlueprintContainerImpl] (pool-7-thread-1) Unable to start blueprint container for bundle example-blueprint: java.lang.IllegalArgumentException: No SchemaFactory that implements the schema language specified by: http://www.w3.org/2001/XMLSchema could be loaded
> 	at javax.xml.validation.SchemaFactory.newInstance(SchemaFactory.java:207) [:1.6.0_26]
> 	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.getSchemaFactory(NamespaceHandlerRegistryImpl.java:266) [NamespaceHandlerRegistryImpl.class:]
> 	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.getSchema(NamespaceHandlerRegistryImpl.java:236) [NamespaceHandlerRegistryImpl.class:]
> 	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.getSchema(NamespaceHandlerRegistryImpl.java:306) [NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.class:]
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 07:20:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Thu, 28 Jul 2011 07:20:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1425) Cannot obtain
 SchemaFactory when TCCL points to ARQ module
Message-ID: <1996596758.88038.1311852023607.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Cannot obtain SchemaFactory when TCCL points to ARQ module
----------------------------------------------------------

                 Key: AS7-1425
                 URL: https://issues.jboss.org/browse/AS7-1425
             Project: Application Server 7
          Issue Type: Bug
          Components: OSGi
            Reporter: Thomas Diesler
            Assignee: Thomas Diesler
             Fix For: 7.1.0.Alpha1


{code}
10:46:41,387 ERROR [org.apache.aries.blueprint.container.BlueprintContainerImpl] (pool-7-thread-1) Unable to start blueprint container for bundle example-blueprint: java.lang.IllegalArgumentException: No SchemaFactory that implements the schema language specified by: http://www.w3.org/2001/XMLSchema could be loaded
	at javax.xml.validation.SchemaFactory.newInstance(SchemaFactory.java:207) [:1.6.0_26]
	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.getSchemaFactory(NamespaceHandlerRegistryImpl.java:266) [NamespaceHandlerRegistryImpl.class:]
	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.getSchema(NamespaceHandlerRegistryImpl.java:236) [NamespaceHandlerRegistryImpl.class:]
	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.getSchema(NamespaceHandlerRegistryImpl.java:306) [NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.class:]
{code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 07:24:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Thu, 28 Jul 2011 07:24:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1425) Cannot obtain
 SchemaFactory when TCCL points to ARQ module
In-Reply-To: <1996596758.88038.1311852023607.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1816725116.88040.1311852263618.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler updated AS7-1425:
--------------------------------

    Description: 
{code}
testSchemaFactoryDefaultTCCL(org.jboss.as.testsuite.integration.osgi.as1424.AS1424TestCase)  Time elapsed: 0.455 sec  <<< ERROR!
java.lang.IllegalArgumentException: No SchemaFactory that implements the schema language specified by: http://www.w3.org/2001/XMLSchema could be loaded
	at javax.xml.validation.SchemaFactory.newInstance(SchemaFactory.java:207)
	at org.jboss.as.testsuite.integration.osgi.as1424.AS1424TestCase.testSchemaFactoryDefaultTCCL(AS1424TestCase.java:74)
{code}

  was:
{code}
10:46:41,387 ERROR [org.apache.aries.blueprint.container.BlueprintContainerImpl] (pool-7-thread-1) Unable to start blueprint container for bundle example-blueprint: java.lang.IllegalArgumentException: No SchemaFactory that implements the schema language specified by: http://www.w3.org/2001/XMLSchema could be loaded
	at javax.xml.validation.SchemaFactory.newInstance(SchemaFactory.java:207) [:1.6.0_26]
	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.getSchemaFactory(NamespaceHandlerRegistryImpl.java:266) [NamespaceHandlerRegistryImpl.class:]
	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl.getSchema(NamespaceHandlerRegistryImpl.java:236) [NamespaceHandlerRegistryImpl.class:]
	at org.apache.aries.blueprint.namespace.NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.getSchema(NamespaceHandlerRegistryImpl.java:306) [NamespaceHandlerRegistryImpl$NamespaceHandlerSetImpl.class:]
{code}



> Cannot obtain SchemaFactory when TCCL points to ARQ module
> ----------------------------------------------------------
>
>                 Key: AS7-1425
>                 URL: https://issues.jboss.org/browse/AS7-1425
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: OSGi
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For: 7.1.0.Alpha1
>
>
> {code}
> testSchemaFactoryDefaultTCCL(org.jboss.as.testsuite.integration.osgi.as1424.AS1424TestCase)  Time elapsed: 0.455 sec  <<< ERROR!
> java.lang.IllegalArgumentException: No SchemaFactory that implements the schema language specified by: http://www.w3.org/2001/XMLSchema could be loaded
> 	at javax.xml.validation.SchemaFactory.newInstance(SchemaFactory.java:207)
> 	at org.jboss.as.testsuite.integration.osgi.as1424.AS1424TestCase.testSchemaFactoryDefaultTCCL(AS1424TestCase.java:74)
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 07:30:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Thu, 28 Jul 2011 07:30:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1425) Cannot obtain
 SchemaFactory when TCCL points to ARQ module
In-Reply-To: <1996596758.88038.1311852023607.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1610714276.88060.1311852623639.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617249#comment-12617249 ] 

Thomas Diesler commented on AS7-1425:
-------------------------------------

This seems to be a general issue. If the TCCL is set to the one of a plain module, the jdk default impl cannot be found. How is this supposed to work? Through its dependencies the module should somehow see these default impls. Is adding them to javax.api an option?

> Cannot obtain SchemaFactory when TCCL points to ARQ module
> ----------------------------------------------------------
>
>                 Key: AS7-1425
>                 URL: https://issues.jboss.org/browse/AS7-1425
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: OSGi
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For: 7.1.0.Alpha1
>
>
> {code}
> testSchemaFactoryDefaultTCCL(org.jboss.as.testsuite.integration.osgi.as1424.AS1424TestCase)  Time elapsed: 0.455 sec  <<< ERROR!
> java.lang.IllegalArgumentException: No SchemaFactory that implements the schema language specified by: http://www.w3.org/2001/XMLSchema could be loaded
> 	at javax.xml.validation.SchemaFactory.newInstance(SchemaFactory.java:207)
> 	at org.jboss.as.testsuite.integration.osgi.as1424.AS1424TestCase.testSchemaFactoryDefaultTCCL(AS1424TestCase.java:74)
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 07:30:23 2011
From: jira-events at lists.jboss.org (Bernard Ligny (JIRA))
Date: Thu, 28 Jul 2011 07:30:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-9424) MDB's are started
 *BEFORE* EJB's are jndi-bound
Message-ID: <360076107.88062.1311852623683.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

MDB's are started *BEFORE* EJB's are jndi-bound
-----------------------------------------------

                 Key: JBAS-9424
                 URL: https://issues.jboss.org/browse/JBAS-9424
             Project: Legacy JBoss Application Server 6 
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB, Weld/CDI
    Affects Versions: 6.0.0.Final
         Environment: All (*NIX, Mac-Os-X and Win)
            Reporter: Bernard Ligny
            Assignee: Carlo de Wolf
            Priority: Critical


I recently noticed a very strange behaviour (with JBOSS AS 6) with Message-Driven-Beans where we inject EJB.

If the JMS queue is empty when the jboss server is started, then everything work's fine.

If, no luck, the jms queue is *NOT* empty, my MDB is apparently mounted *BEFORE* the ejb's
and the @Inject failed:
=> "Failure WELD-000079 Could not find the EJB in JNDI:  class xxx"


I further investigated the problem:
I replaced the @Inject annotation, with a "manual" lookup of my ejb 
using the javax.enterprise.inject.spi.BeanManager capabilities (that i put in a @Postcontruct method of my MDB), 
The trick consisted in trying the lookup n times with a delay of x sec between each attempt.

Here are the results (excerpt from server.log):

2011-07-28 12:05:06,180 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [1] Trying to lookup KernelResources
2011-07-28 12:05:06,190 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [1] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
...
2011-07-28 12:05:11,191 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [2] Trying to lookup KernelResources
2011-07-28 12:05:11,192 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [2] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
...
2011-07-28 12:05:16,193 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [3] Trying to lookup KernelResources
2011-07-28 12:05:16,193 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [3] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
...
2011-07-28 12:05:21,194 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [4] Trying to lookup KernelResources
2011-07-28 12:05:21,194 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [4] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
...
2011-07-28 12:05:26,195 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [5] Trying to lookup KernelResources
2011-07-28 12:05:26,195 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [5] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
...
2011-07-28 12:05:26,215 INFO  [org.jboss.ejb3.nointerface.impl.jndi.AbstractNoInterfaceViewBinder] (Thread-3) Binding the following entry in Global JNDI for bean:KernelResources
=> finally the EJB is bound !

2011-07-28 12:05:31,196 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [6] Trying to lookup KernelResources
2011-07-28 12:05:31,197 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** KernelResources = No-Interface view for endpoint [ jboss.j2ee:ear=energycomm-ear.ear,jar=energycomm-kernel-0.5.0-SNAPSHOT.jar,name=KernelResources,service=EJB3 ]
=> the 6th attempt now works :-)

Conclusion: according to me, there is no doubt: dependencies between MDB's and EJB's are not correctly managed by the app server.
The app server should wait for all EJB's to be bound before activating the MDB.
MDB are activated too early (especially when jms queue is not empty at starttime)





--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 07:44:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Thu, 28 Jul 2011 07:44:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1425) Cannot obtain
 SchemaFactory when TCCL points to ARQ module
In-Reply-To: <1996596758.88038.1311852023607.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2118376505.88111.1311853463617.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler reassigned AS7-1425:
-----------------------------------

    Assignee: David Lloyd  (was: Thomas Diesler)


> Cannot obtain SchemaFactory when TCCL points to ARQ module
> ----------------------------------------------------------
>
>                 Key: AS7-1425
>                 URL: https://issues.jboss.org/browse/AS7-1425
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: OSGi
>            Reporter: Thomas Diesler
>            Assignee: David Lloyd
>             Fix For: 7.1.0.Alpha1
>
>
> {code}
> testSchemaFactoryDefaultTCCL(org.jboss.as.testsuite.integration.osgi.as1424.AS1424TestCase)  Time elapsed: 0.455 sec  <<< ERROR!
> java.lang.IllegalArgumentException: No SchemaFactory that implements the schema language specified by: http://www.w3.org/2001/XMLSchema could be loaded
> 	at javax.xml.validation.SchemaFactory.newInstance(SchemaFactory.java:207)
> 	at org.jboss.as.testsuite.integration.osgi.as1424.AS1424TestCase.testSchemaFactoryDefaultTCCL(AS1424TestCase.java:74)
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 07:48:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Thu, 28 Jul 2011 07:48:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1301) Update OSGi to be
 compatible with JBoss Modules 1.1 series
In-Reply-To: <970188.57854.1310766324068.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <6742996.88125.1311853703693.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617255#comment-12617255 ] 

Thomas Diesler commented on AS7-1301:
-------------------------------------

Pull Request Sent 

> Update OSGi to be compatible with JBoss Modules 1.1 series
> ----------------------------------------------------------
>
>                 Key: AS7-1301
>                 URL: https://issues.jboss.org/browse/AS7-1301
>             Project: Application Server 7
>          Issue Type: Task
>          Components: OSGi
>            Reporter: David Lloyd
>            Assignee: Thomas Diesler
>             Fix For: 7.1.0.Alpha1
>
>
> JBoss Modules 1.1 has two significant changes.  First, jaxpmodule is eliminated.  Second, the system module is no more - instead there's a dependency type for the system class loader.
> I currently have an updated AS in my http://github.com/dmlloyd/jboss-as/tree/upgrades branch.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 07:53:23 2011
From: jira-events at lists.jboss.org (Bernard Ligny (JIRA))
Date: Thu, 28 Jul 2011 07:53:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-9424) MDB's are started
 *BEFORE* EJB's are jndi-bound
In-Reply-To: <360076107.88062.1311852623683.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1602795756.88134.1311854003746.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBAS-9424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bernard Ligny updated JBAS-9424:
--------------------------------

    Description: 
I recently noticed a very strange behaviour (with JBOSS AS 6) with Message-Driven-Beans where we inject EJB.

If the JMS queue is empty when the jboss server is started, then everything works fine.

If, no luck, the jms queue is *NOT* empty, my MDB is apparently mounted *BEFORE* the ejb's
and the @Inject failed:
=> "Failure WELD-000079 Could not find the EJB in JNDI:  class xxx"


I further investigated the problem:
I replaced the @Inject annotation, with a "manual" lookup of my ejb 
using the javax.enterprise.inject.spi.BeanManager capabilities (that i put in a @Postcontruct method of my MDB), 
The trick consisted in trying the lookup n times with a delay of x sec between each attempt.

Here are the results (excerpt from server.log):

{code:xml} 
2011-07-28 12:05:06,180 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [1] Trying to lookup KernelResources
2011-07-28 12:05:06,190 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [1] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
...
2011-07-28 12:05:11,191 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [2] Trying to lookup KernelResources
2011-07-28 12:05:11,192 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [2] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
...
2011-07-28 12:05:16,193 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [3] Trying to lookup KernelResources
2011-07-28 12:05:16,193 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [3] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
...
2011-07-28 12:05:21,194 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [4] Trying to lookup KernelResources
2011-07-28 12:05:21,194 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [4] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
...
2011-07-28 12:05:26,195 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [5] Trying to lookup KernelResources
2011-07-28 12:05:26,195 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [5] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
...
2011-07-28 12:05:26,215 INFO  [org.jboss.ejb3.nointerface.impl.jndi.AbstractNoInterfaceViewBinder] (Thread-3) Binding the following entry in Global JNDI for bean:KernelResources
=> finally the EJB is bound !

2011-07-28 12:05:31,196 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [6] Trying to lookup KernelResources
2011-07-28 12:05:31,197 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** KernelResources = No-Interface view for endpoint [ jboss.j2ee:ear=energycomm-ear.ear,jar=energycomm-kernel-0.5.0-SNAPSHOT.jar,name=KernelResources,service=EJB3 ]
=> the 6th attempt now works :-)
{code} 


Conclusion: according to me, there is no doubt: dependencies between MDB's and EJB's are not correctly managed by the app server.
The app server should wait for all EJB's to be bound before activating the MDB.
MDB are activated too early (especially when jms queue is not empty at starttime)





  was:
I recently noticed a very strange behaviour (with JBOSS AS 6) with Message-Driven-Beans where we inject EJB.

If the JMS queue is empty when the jboss server is started, then everything work's fine.

If, no luck, the jms queue is *NOT* empty, my MDB is apparently mounted *BEFORE* the ejb's
and the @Inject failed:
=> "Failure WELD-000079 Could not find the EJB in JNDI:  class xxx"


I further investigated the problem:
I replaced the @Inject annotation, with a "manual" lookup of my ejb 
using the javax.enterprise.inject.spi.BeanManager capabilities (that i put in a @Postcontruct method of my MDB), 
The trick consisted in trying the lookup n times with a delay of x sec between each attempt.

Here are the results (excerpt from server.log):

2011-07-28 12:05:06,180 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [1] Trying to lookup KernelResources
2011-07-28 12:05:06,190 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [1] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
...
2011-07-28 12:05:11,191 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [2] Trying to lookup KernelResources
2011-07-28 12:05:11,192 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [2] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
...
2011-07-28 12:05:16,193 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [3] Trying to lookup KernelResources
2011-07-28 12:05:16,193 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [3] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
...
2011-07-28 12:05:21,194 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [4] Trying to lookup KernelResources
2011-07-28 12:05:21,194 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [4] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
...
2011-07-28 12:05:26,195 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [5] Trying to lookup KernelResources
2011-07-28 12:05:26,195 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [5] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
...
2011-07-28 12:05:26,215 INFO  [org.jboss.ejb3.nointerface.impl.jndi.AbstractNoInterfaceViewBinder] (Thread-3) Binding the following entry in Global JNDI for bean:KernelResources
=> finally the EJB is bound !

2011-07-28 12:05:31,196 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [6] Trying to lookup KernelResources
2011-07-28 12:05:31,197 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** KernelResources = No-Interface view for endpoint [ jboss.j2ee:ear=energycomm-ear.ear,jar=energycomm-kernel-0.5.0-SNAPSHOT.jar,name=KernelResources,service=EJB3 ]
=> the 6th attempt now works :-)

Conclusion: according to me, there is no doubt: dependencies between MDB's and EJB's are not correctly managed by the app server.
The app server should wait for all EJB's to be bound before activating the MDB.
MDB are activated too early (especially when jms queue is not empty at starttime)







> MDB's are started *BEFORE* EJB's are jndi-bound
> -----------------------------------------------
>
>                 Key: JBAS-9424
>                 URL: https://issues.jboss.org/browse/JBAS-9424
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB, Weld/CDI
>    Affects Versions: 6.0.0.Final
>         Environment: All (*NIX, Mac-Os-X and Win)
>            Reporter: Bernard Ligny
>            Assignee: Carlo de Wolf
>            Priority: Critical
>
> I recently noticed a very strange behaviour (with JBOSS AS 6) with Message-Driven-Beans where we inject EJB.
> If the JMS queue is empty when the jboss server is started, then everything works fine.
> If, no luck, the jms queue is *NOT* empty, my MDB is apparently mounted *BEFORE* the ejb's
> and the @Inject failed:
> => "Failure WELD-000079 Could not find the EJB in JNDI:  class xxx"
> I further investigated the problem:
> I replaced the @Inject annotation, with a "manual" lookup of my ejb 
> using the javax.enterprise.inject.spi.BeanManager capabilities (that i put in a @Postcontruct method of my MDB), 
> The trick consisted in trying the lookup n times with a delay of x sec between each attempt.
> Here are the results (excerpt from server.log):
> {code:xml} 
> 2011-07-28 12:05:06,180 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [1] Trying to lookup KernelResources
> 2011-07-28 12:05:06,190 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [1] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:11,191 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [2] Trying to lookup KernelResources
> 2011-07-28 12:05:11,192 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [2] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:16,193 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [3] Trying to lookup KernelResources
> 2011-07-28 12:05:16,193 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [3] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:21,194 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [4] Trying to lookup KernelResources
> 2011-07-28 12:05:21,194 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [4] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:26,195 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [5] Trying to lookup KernelResources
> 2011-07-28 12:05:26,195 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [5] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:26,215 INFO  [org.jboss.ejb3.nointerface.impl.jndi.AbstractNoInterfaceViewBinder] (Thread-3) Binding the following entry in Global JNDI for bean:KernelResources
> => finally the EJB is bound !
> 2011-07-28 12:05:31,196 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [6] Trying to lookup KernelResources
> 2011-07-28 12:05:31,197 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** KernelResources = No-Interface view for endpoint [ jboss.j2ee:ear=energycomm-ear.ear,jar=energycomm-kernel-0.5.0-SNAPSHOT.jar,name=KernelResources,service=EJB3 ]
> => the 6th attempt now works :-)
> {code} 
> Conclusion: according to me, there is no doubt: dependencies between MDB's and EJB's are not correctly managed by the app server.
> The app server should wait for all EJB's to be bound before activating the MDB.
> MDB are activated too early (especially when jms queue is not empty at starttime)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 08:15:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 28 Jul 2011 08:15:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1271) Fired object messages
 violate classloaders
In-Reply-To: <886860909.49673.1310523023634.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1156728003.88263.1311855323858.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated AS7-1271:
------------------------------

         Assignee: Clebert Suconic
    Fix Version/s: 7.0.1.Final
      Component/s: JMS


> Fired object messages violate classloaders
> ------------------------------------------
>
>                 Key: AS7-1271
>                 URL: https://issues.jboss.org/browse/AS7-1271
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMS
>            Reporter: John Ament
>            Assignee: Clebert Suconic
>             Fix For: 7.0.1.Final
>
>
> JMS allows you to fire an object message.  In this case, I have a object of type in my deployment.  It fires fine.  I bind a message consumer to a queue in AS7.  the object message coming in results in a classloader violation:
> 22:13:35,116 ERROR [org.jboss.seam.jms.example.statuswatcher.messagedriven.DistributorMDB] (Thread-2 (group:HornetQ-client-global-threads-767046602)) org.jboss.seam.jms.example.statuswatcher.model.Status from [Module "org.hornetq:main" from local module loader @19d009b4 (roots: /apps/jboss-as-7.0.0.Final/modules)]: javax.jms.JMSException: org.jboss.seam.jms.example.statuswatcher.model.Status from [Module "org.hornetq:main" from local module loader @19d009b4 (roots: /apps/jboss-as-7.0.0.Final/modules)]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
> 	at java.lang.Class.forName0(Native Method) [:1.6.0_22]
> 	at java.lang.Class.forName(Class.java:247) [:1.6.0_22]
> 	at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:603) [:1.6.0_22]
> 	at org.hornetq.utils.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:69) [hornetq-core-2.2.6.Final.jar:]
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1574) [:1.6.0_22]
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495) [:1.6.0_22]
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731) [:1.6.0_22]
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) [:1.6.0_22]
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) [:1.6.0_22]
> 	at org.hornetq.jms.client.HornetQObjectMessage.getObject(HornetQObjectMessage.java:158) [hornetq-jms-2.2.6.Final.jar:]
> 	at org.jboss.seam.jms.example.statuswatcher.messagedriven.DistributorMDB.onMessage(DistributorMDB.java:46)
> 	at org.hornetq.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:91) [hornetq-jms-2.2.6.Final.jar:]
> 	at org.hornetq.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:866) [hornetq-core-2.2.6.Final.jar:]
> 	at org.hornetq.core.client.impl.ClientConsumerImpl.access$100(ClientConsumerImpl.java:44) [hornetq-core-2.2.6.Final.jar:]
> 	at org.hornetq.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:983) [hornetq-core-2.2.6.Final.jar:]
> 	at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.6.Final.jar:]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_22]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_22]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_22]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 08:17:23 2011
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Thu, 28 Jul 2011 08:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1271) Fired object messages
 violate classloaders
In-Reply-To: <886860909.49673.1310523023634.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1741601736.88271.1311855443763.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

SBS JIRA Integration updated AS7-1271:
--------------------------------------

    Forum Reference: http://community.jboss.org/message/618058#618058


> Fired object messages violate classloaders
> ------------------------------------------
>
>                 Key: AS7-1271
>                 URL: https://issues.jboss.org/browse/AS7-1271
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMS
>            Reporter: John Ament
>            Assignee: Clebert Suconic
>             Fix For: 7.0.1.Final
>
>
> JMS allows you to fire an object message.  In this case, I have a object of type in my deployment.  It fires fine.  I bind a message consumer to a queue in AS7.  the object message coming in results in a classloader violation:
> 22:13:35,116 ERROR [org.jboss.seam.jms.example.statuswatcher.messagedriven.DistributorMDB] (Thread-2 (group:HornetQ-client-global-threads-767046602)) org.jboss.seam.jms.example.statuswatcher.model.Status from [Module "org.hornetq:main" from local module loader @19d009b4 (roots: /apps/jboss-as-7.0.0.Final/modules)]: javax.jms.JMSException: org.jboss.seam.jms.example.statuswatcher.model.Status from [Module "org.hornetq:main" from local module loader @19d009b4 (roots: /apps/jboss-as-7.0.0.Final/modules)]
> 	at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
> 	at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
> 	at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
> 	at java.lang.Class.forName0(Native Method) [:1.6.0_22]
> 	at java.lang.Class.forName(Class.java:247) [:1.6.0_22]
> 	at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:603) [:1.6.0_22]
> 	at org.hornetq.utils.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:69) [hornetq-core-2.2.6.Final.jar:]
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1574) [:1.6.0_22]
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495) [:1.6.0_22]
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731) [:1.6.0_22]
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) [:1.6.0_22]
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) [:1.6.0_22]
> 	at org.hornetq.jms.client.HornetQObjectMessage.getObject(HornetQObjectMessage.java:158) [hornetq-jms-2.2.6.Final.jar:]
> 	at org.jboss.seam.jms.example.statuswatcher.messagedriven.DistributorMDB.onMessage(DistributorMDB.java:46)
> 	at org.hornetq.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:91) [hornetq-jms-2.2.6.Final.jar:]
> 	at org.hornetq.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:866) [hornetq-core-2.2.6.Final.jar:]
> 	at org.hornetq.core.client.impl.ClientConsumerImpl.access$100(ClientConsumerImpl.java:44) [hornetq-core-2.2.6.Final.jar:]
> 	at org.hornetq.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:983) [hornetq-core-2.2.6.Final.jar:]
> 	at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.6.Final.jar:]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_22]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_22]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_22]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 09:06:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Thu, 28 Jul 2011 09:06:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1426) Provide injectable
 BundleContext in JNDI
Message-ID: <2100281757.88415.1311858383865.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Provide injectable BundleContext in JNDI
----------------------------------------

                 Key: AS7-1426
                 URL: https://issues.jboss.org/browse/AS7-1426
             Project: Application Server 7
          Issue Type: Feature Request
          Components: OSGi
            Reporter: Thomas Diesler
            Assignee: Thomas Diesler
             Fix For: 7.1.0.Alpha1


The system BundleContext should be available as injectable resource

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 09:10:23 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 28 Jul 2011 09:10:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1893) Using
 separate threads to stop message sucker
Message-ID: <1681405433.88423.1311858623682.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Using separate threads to stop message sucker
---------------------------------------------

                 Key: JBMESSAGING-1893
                 URL: https://issues.jboss.org/browse/JBMESSAGING-1893
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Clustering
    Affects Versions: 1.4.8.SP2, 1.4.0.SP3.CP14
            Reporter: Yong Hao Gao
            Assignee: Yong Hao Gao
             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3


Stopping MessageSuckers involve remoting operations (such as close consumer) and that may take a long time blocking if the network has problems. Easpecially during failover, the stop of suckers are executed in the thread of jgroups, which doesn't expect any long blocking operations. It should be executed using separate threads (pool).
 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 09:20:23 2011
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Thu, 28 Jul 2011 09:20:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-270) Intermittent
 failure of undeploy
In-Reply-To: <199739023.3169.1299196425630.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1648898873.88448.1311859223695.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBDEPLOY-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617274#comment-12617274 ] 

Ales Justin commented on JBDEPLOY-270:
--------------------------------------

I still don't see how unordered set causes duplicate registry.


> Intermittent failure of undeploy
> --------------------------------
>
>                 Key: JBDEPLOY-270
>                 URL: https://issues.jboss.org/browse/JBDEPLOY-270
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions:  JBDEPLOY-2.0.10.GA 
>            Reporter: Dennis Reed
>         Attachments: JBDEPLOY-270-jboss-beans.xml
>
>
> When components are deployed, they are assigned names with a number appended based on the order it was processed.
> For example "jboss.deployment:id="dennis$defaultEvictionRegionConfig#1",type=Component"
> The number is assigned in (line #'s are from EAP 5.0):
>     at org.jboss.beans.metadata.plugins.AbstractBeanMetaData.setName(AbstractBeanMetaData.java:360)
>     at org.jboss.beans.metadata.plugins.NestedBeanHandler.checkForNestedBeans(NestedBeanHandler.java:77)
>     at org.jboss.beans.metadata.plugins.AbstractBeanMetaData.getBeans(AbstractBeanMetaData.java:202)
>     at org.jboss.kernel.plugins.deployment.AbstractKernelDeployment.getBeans(AbstractKernelDeployment.java:233)
>     at org.jboss.deployers.vfs.deployer.kernel.KernelDeploymentDeployer$KernelDeploymentVisitor.getBeans(KernelDeploymentDeployer.java:63)
>     at org.jboss.deployers.vfs.deployer.kernel.KernelDeploymentDeployer$KernelDeploymentVisitor.getBeans(KernelDeploymentDeployer.java:54)
>     at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryVisitor.deploy(BeanMetaDataFactoryVisitor.java:118)
> However, the beans are *not* processed in the same order every time.
> And they are processed separately during deployment and undeployment.
> This means that "myBean#1" may get deployed, but "myBean#2" is undeployed (leaving "myBean#1" still deployed).
> Subsequent deployments will fail with errors:
> 17:34:30,630 WARN  [AbstractDeploymentContext] Unable to register deployment mbean dennis$defaultEvictionRegionConfig#1
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="dennis$defaultEvictionRegionConfig#1",type=Component already registered.
> The root cause appears to be that the XML descriptor is read with jboss-xb using a Set (unordered), but then 
> this code has a dependency on the order being consistent between deploy and undeploy.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 09:41:23 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Thu, 28 Jul 2011 09:41:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1427) tags mapped to model
 with different names lead sometime to exception deifficult to understand
 for normal users
Message-ID: <1314763702.88485.1311860483678.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

tags mapped to model with different names lead sometime to exception deifficult to understand for normal users
--------------------------------------------------------------------------------------------------------------

                 Key: AS7-1427
                 URL: https://issues.jboss.org/browse/AS7-1427
             Project: Application Server 7
          Issue Type: Task
          Components: JCA
            Reporter: Stefano Maestri
            Assignee: Jeff Zhang
             Fix For: 7.1.0.Alpha1


See forum post

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 09:45:23 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Thu, 28 Jul 2011 09:45:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1428) Throw an error when a
 driver is not loaded due to wrong driver-classname
Message-ID: <1631144753.88504.1311860723759.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Throw an error when a driver is not loaded due to wrong driver-classname 
-------------------------------------------------------------------------

                 Key: AS7-1428
                 URL: https://issues.jboss.org/browse/AS7-1428
             Project: Application Server 7
          Issue Type: Task
          Components: JCA
            Reporter: Stefano Maestri
            Assignee: Jeff Zhang
             Fix For: 7.1.0.Alpha1


See forum post

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 09:45:23 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Thu, 28 Jul 2011 09:45:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1428) Throw an error when a
 driver is not loaded due to wrong driver-classname
In-Reply-To: <1631144753.88504.1311860723759.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1313323525.88508.1311860723876.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefano Maestri updated AS7-1428:
---------------------------------

    Forum Reference: http://community.jboss.org/message/617978  (was: http://community.jboss.org/message/617978#617978)


> Throw an error when a driver is not loaded due to wrong driver-classname 
> -------------------------------------------------------------------------
>
>                 Key: AS7-1428
>                 URL: https://issues.jboss.org/browse/AS7-1428
>             Project: Application Server 7
>          Issue Type: Task
>          Components: JCA
>            Reporter: Stefano Maestri
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.Alpha1
>
>
> See forum post

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 09:45:24 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Thu, 28 Jul 2011 09:45:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1428) Throw an error when a
 driver is not loaded due to wrong driver-classname
In-Reply-To: <1631144753.88504.1311860723759.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1274447552.88515.1311860724051.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefano Maestri updated AS7-1428:
---------------------------------

    Forum Reference: http://community.jboss.org/message/618097#618097  (was: http://community.jboss.org/message/617978)


> Throw an error when a driver is not loaded due to wrong driver-classname 
> -------------------------------------------------------------------------
>
>                 Key: AS7-1428
>                 URL: https://issues.jboss.org/browse/AS7-1428
>             Project: Application Server 7
>          Issue Type: Task
>          Components: JCA
>            Reporter: Stefano Maestri
>            Assignee: Jeff Zhang
>             Fix For: 7.1.0.Alpha1
>
>
> See forum post

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 09:47:23 2011
From: jira-events at lists.jboss.org (Strong Liu (JIRA))
Date: Thu, 28 Jul 2011 09:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-9425) Upgrade to hibernate
	3.6.6-Final
Message-ID: <808838393.88519.1311860843825.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Upgrade to hibernate 3.6.6-Final
--------------------------------

                 Key: JBAS-9425
                 URL: https://issues.jboss.org/browse/JBAS-9425
             Project: Legacy JBoss Application Server 6 
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: JPA / Hibernate
            Reporter: Strong Liu
            Assignee: Strong Liu
             Fix For: 6.1.0




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 09:55:23 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Thu, 28 Jul 2011 09:55:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1428) Throw an error when
 a driver is not loaded due to wrong driver-classname
In-Reply-To: <1631144753.88504.1311860723759.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <701161781.88538.1311861323767.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefano Maestri reassigned AS7-1428:
------------------------------------

    Assignee: Stefano Maestri  (was: Jeff Zhang)


> Throw an error when a driver is not loaded due to wrong driver-classname 
> -------------------------------------------------------------------------
>
>                 Key: AS7-1428
>                 URL: https://issues.jboss.org/browse/AS7-1428
>             Project: Application Server 7
>          Issue Type: Task
>          Components: JCA
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>             Fix For: 7.1.0.Alpha1
>
>
> See forum post

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 10:12:24 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Thu, 28 Jul 2011 10:12:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1350) Add management
 operations to assign/unassign handlers from loggers and async handlers.
In-Reply-To: <788349166.68808.1311164783691.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <627815499.88591.1311862344039.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617285#comment-12617285 ] 

David Lloyd commented on AS7-1350:
----------------------------------

I see - the root logger should be a resource, not something flattened into the base structure.  Might make sense to manage the root logger under the logger name "" for this purpose, or something like that, so that it can be addressed separately from the main root.

> Add management operations to assign/unassign handlers from loggers and async handlers.
> --------------------------------------------------------------------------------------
>
>                 Key: AS7-1350
>                 URL: https://issues.jboss.org/browse/AS7-1350
>             Project: Application Server 7
>          Issue Type: Feature Request
>    Affects Versions: 7.0.0.Final
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>             Fix For: 7.1.0.Alpha1
>
>
> Proposed new management operations:
> For Async Handler:
> assign-subhandler
> unassign-subhandler
> For Root Logger:
> root-logger-assign-handler
> root-logger-unassign-handler
> For other Loggers:
> assign-handler
> unassign-handler

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 10:23:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Thu, 28 Jul 2011 10:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1425) Cannot obtain
 SchemaFactory when TCCL points to ARQ module
In-Reply-To: <1996596758.88038.1311852023607.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <120027709.88606.1311863003770.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617287#comment-12617287 ] 

David Lloyd commented on AS7-1425:
----------------------------------

JBoss Modules 1.0.x has a redirection facility that we're discarding in 1.1.  The ongoing solution is that we are going to use endorsed JARs to override the JAXP APIs and those will be module-aware and able to load implementations.

> Cannot obtain SchemaFactory when TCCL points to ARQ module
> ----------------------------------------------------------
>
>                 Key: AS7-1425
>                 URL: https://issues.jboss.org/browse/AS7-1425
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: OSGi
>            Reporter: Thomas Diesler
>            Assignee: David Lloyd
>             Fix For: 7.1.0.Alpha1
>
>
> {code}
> testSchemaFactoryDefaultTCCL(org.jboss.as.testsuite.integration.osgi.as1424.AS1424TestCase)  Time elapsed: 0.455 sec  <<< ERROR!
> java.lang.IllegalArgumentException: No SchemaFactory that implements the schema language specified by: http://www.w3.org/2001/XMLSchema could be loaded
> 	at javax.xml.validation.SchemaFactory.newInstance(SchemaFactory.java:207)
> 	at org.jboss.as.testsuite.integration.osgi.as1424.AS1424TestCase.testSchemaFactoryDefaultTCCL(AS1424TestCase.java:74)
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 10:23:23 2011
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Thu, 28 Jul 2011 10:23:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1350) Add management
 operations to assign/unassign handlers from loggers and async handlers.
In-Reply-To: <788349166.68808.1311164783691.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1014752986.88610.1311863003862.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617288#comment-12617288 ] 

Stan Silvert commented on AS7-1350:
-----------------------------------

That would make things a lot simpler.  It would allow you to remove a lot of code.  But I'd rather see it named "root-logger" so that it's obvious what you are looking at.  Calling it "" might look like something is corrupted.


> Add management operations to assign/unassign handlers from loggers and async handlers.
> --------------------------------------------------------------------------------------
>
>                 Key: AS7-1350
>                 URL: https://issues.jboss.org/browse/AS7-1350
>             Project: Application Server 7
>          Issue Type: Feature Request
>    Affects Versions: 7.0.0.Final
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>             Fix For: 7.1.0.Alpha1
>
>
> Proposed new management operations:
> For Async Handler:
> assign-subhandler
> unassign-subhandler
> For Root Logger:
> root-logger-assign-handler
> root-logger-unassign-handler
> For other Loggers:
> assign-handler
> unassign-handler

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 10:25:23 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Thu, 28 Jul 2011 10:25:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1425) Cannot obtain
 SchemaFactory when TCCL points to ARQ module
In-Reply-To: <1996596758.88038.1311852023607.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1684555881.88631.1311863123974.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617290#comment-12617290 ] 

David Lloyd commented on AS7-1425:
----------------------------------

As a temporary workaround, if you want to, you could set the TCCL to the implementation module for the duration of these tests, or in the case of this test, simply disable it for now until AS7-1302 comes im.

> Cannot obtain SchemaFactory when TCCL points to ARQ module
> ----------------------------------------------------------
>
>                 Key: AS7-1425
>                 URL: https://issues.jboss.org/browse/AS7-1425
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: OSGi
>            Reporter: Thomas Diesler
>            Assignee: David Lloyd
>             Fix For: 7.1.0.Alpha1
>
>
> {code}
> testSchemaFactoryDefaultTCCL(org.jboss.as.testsuite.integration.osgi.as1424.AS1424TestCase)  Time elapsed: 0.455 sec  <<< ERROR!
> java.lang.IllegalArgumentException: No SchemaFactory that implements the schema language specified by: http://www.w3.org/2001/XMLSchema could be loaded
> 	at javax.xml.validation.SchemaFactory.newInstance(SchemaFactory.java:207)
> 	at org.jboss.as.testsuite.integration.osgi.as1424.AS1424TestCase.testSchemaFactoryDefaultTCCL(AS1424TestCase.java:74)
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 10:36:24 2011
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Thu, 28 Jul 2011 10:36:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1350) Add management
 operations to assign/unassign handlers from loggers and async handlers.
In-Reply-To: <788349166.68808.1311164783691.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1681601181.88659.1311863784611.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617292#comment-12617292 ] 

David Lloyd commented on AS7-1350:
----------------------------------

I see what you're saying, however "root-logger" is actually a valid (if silly) logger name.  "" is the actual name of the root logger.  One option would be to start the name with a "." though: ".root-logger" or something.  That's the only readable-yet-invalid logger name I can think of.

> Add management operations to assign/unassign handlers from loggers and async handlers.
> --------------------------------------------------------------------------------------
>
>                 Key: AS7-1350
>                 URL: https://issues.jboss.org/browse/AS7-1350
>             Project: Application Server 7
>          Issue Type: Feature Request
>    Affects Versions: 7.0.0.Final
>            Reporter: Stan Silvert
>            Assignee: Stan Silvert
>             Fix For: 7.1.0.Alpha1
>
>
> Proposed new management operations:
> For Async Handler:
> assign-subhandler
> unassign-subhandler
> For Root Logger:
> root-logger-assign-handler
> root-logger-unassign-handler
> For other Loggers:
> assign-handler
> unassign-handler

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 11:04:23 2011
From: jira-events at lists.jboss.org (Bernard Ligny (JIRA))
Date: Thu, 28 Jul 2011 11:04:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-9424) MDB's are started
 *BEFORE* EJB's are jndi-bound
In-Reply-To: <360076107.88062.1311852623683.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <652423113.88830.1311865463704.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBAS-9424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617306#comment-12617306 ] 

Bernard Ligny commented on JBAS-9424:
-------------------------------------

This is somewhat simimar to JBAS-4083.
In this particular case, the MDB fires before the ear completely deploys

> MDB's are started *BEFORE* EJB's are jndi-bound
> -----------------------------------------------
>
>                 Key: JBAS-9424
>                 URL: https://issues.jboss.org/browse/JBAS-9424
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB, Weld/CDI
>    Affects Versions: 6.0.0.Final
>         Environment: All (*NIX, Mac-Os-X and Win)
>            Reporter: Bernard Ligny
>            Assignee: Carlo de Wolf
>            Priority: Critical
>
> I recently noticed a very strange behaviour (with JBOSS AS 6) with Message-Driven-Beans where we inject EJB.
> If the JMS queue is empty when the jboss server is started, then everything works fine.
> If, no luck, the jms queue is *NOT* empty, my MDB is apparently mounted *BEFORE* the ejb's
> and the @Inject failed:
> => "Failure WELD-000079 Could not find the EJB in JNDI:  class xxx"
> I further investigated the problem:
> I replaced the @Inject annotation, with a "manual" lookup of my ejb 
> using the javax.enterprise.inject.spi.BeanManager capabilities (that i put in a @Postcontruct method of my MDB), 
> The trick consisted in trying the lookup n times with a delay of x sec between each attempt.
> Here are the results (excerpt from server.log):
> {code:xml} 
> 2011-07-28 12:05:06,180 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [1] Trying to lookup KernelResources
> 2011-07-28 12:05:06,190 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [1] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:11,191 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [2] Trying to lookup KernelResources
> 2011-07-28 12:05:11,192 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [2] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:16,193 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [3] Trying to lookup KernelResources
> 2011-07-28 12:05:16,193 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [3] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:21,194 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [4] Trying to lookup KernelResources
> 2011-07-28 12:05:21,194 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [4] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:26,195 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [5] Trying to lookup KernelResources
> 2011-07-28 12:05:26,195 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [5] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:26,215 INFO  [org.jboss.ejb3.nointerface.impl.jndi.AbstractNoInterfaceViewBinder] (Thread-3) Binding the following entry in Global JNDI for bean:KernelResources
> => finally the EJB is bound !
> 2011-07-28 12:05:31,196 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [6] Trying to lookup KernelResources
> 2011-07-28 12:05:31,197 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** KernelResources = No-Interface view for endpoint [ jboss.j2ee:ear=energycomm-ear.ear,jar=energycomm-kernel-0.5.0-SNAPSHOT.jar,name=KernelResources,service=EJB3 ]
> => the 6th attempt now works :-)
> {code} 
> Conclusion: according to me, there is no doubt: dependencies between MDB's and EJB's are not correctly managed by the app server.
> The app server should wait for all EJB's to be bound before activating the MDB.
> MDB are activated too early (especially when jms queue is not empty at starttime)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 11:04:23 2011
From: jira-events at lists.jboss.org (Manuel Bogner (JIRA))
Date: Thu, 28 Jul 2011 11:04:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1429) jboss-javaee6-webapp
 and webservices
Message-ID: <1748609762.88837.1311865463959.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

jboss-javaee6-webapp and webservices
------------------------------------

                 Key: AS7-1429
                 URL: https://issues.jboss.org/browse/AS7-1429
             Project: Application Server 7
          Issue Type: Bug
          Components: CDI / Weld, Web Services
    Affects Versions: 7.0.0.Final
         Environment: ubuntu
            Reporter: Manuel Bogner
            Assignee: Stuart Douglas
             Fix For: No Release


hi,

i installed a plain maven jboss-javaee6-webapp webapp to have a look at the new as7. deploying the application works fine and i can access http://localhost:8080/as7/index.jsf

then i tried to add a simple soap-webservice by adding to my standalone.xml:

...
<extensions>
...
        <extension module="org.jboss.as.webservices"/>
...
    </extensions>
...
    <subsystem xmlns="urn:jboss:domain:webservices:1.0" xmlns:javaee="http://java.sun.com/xml/ns/javaee" xmlns:jaxwsconfig="urn:jboss:jbossws-jaxws-config:4.0">
            <wsdl-host>
                localhost
            </wsdl-host>
            <modify-wsdl-address>
                true
            </modify-wsdl-address>
        </subsystem>
...


copy pasted from the standalone-preview.xml


the webservice looks like the following and works as expected:

import javax.ejb.Stateless;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;

/**
 * @author manuel
 *
 */
@WebService
@Stateless
public class TestService {
	
	@WebMethod
	public String echo(@WebParam final String toEcho) {
		return toEcho;
	}

}


but if i try to access the web content i only get the following error:

17:03:00,453 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/as7].[FacesServlet]] (http--127.0.0.1-8080-3) Servlet.service() for servlet FacesServlet threw exception: java.lang.IllegalStateException: Must call associate() before calling activate()
	at org.jboss.weld.context.AbstractConversationContext.activate(AbstractConversationContext.java:277) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
	at org.jboss.weld.jsf.WeldPhaseListener.activateConversations(WeldPhaseListener.java:114) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
	at org.jboss.weld.jsf.WeldPhaseListener.beforePhase(WeldPhaseListener.java:88) [weld-core-1.1.2.AS7.jar:2011-07-06 12:26]
	at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
	at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:111) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.0.4-b09-jbossorg-4.jar:2.0.4-b09-jbossorg-4]
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312) [jboss-jsf-api_2.0_spec-1.0.0.Final.jar:1.0.0.Final]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.0.Final.jar:7.0.0.Final]
	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.0.0.Final.jar:7.0.0.Final]
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [jbossweb-7.0.0.CR4.jar:7.0.0.Final]
	at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 11:08:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Thu, 28 Jul 2011 11:08:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-1426) Provide
 injectable BundleContext in JNDI
In-Reply-To: <2100281757.88415.1311858383865.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1046544892.88849.1311865703685.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617307#comment-12617307 ] 

Thomas Diesler edited comment on AS7-1426 at 7/28/11 11:08 AM:
---------------------------------------------------------------

This works and is ready for review
https://github.com/tdiesler/jboss-as/commit/8750bfc6

{code}
@Stateless
@LocalBean
public class SimpleStatelessSessionBean implements Echo {

    @Resource(lookup = "java:global/osgi/BundleContext")
    private BundleContext context;
{code}

      was (Author: thomas.diesler):
    This works and is ready for review
https://github.com/tdiesler/jboss-as/commit/8750bf

{code}
@Stateless
@LocalBean
public class SimpleStatelessSessionBean implements Echo {

    @Resource(lookup = "java:global/osgi/BundleContext")
    private BundleContext context;
{code}
  
> Provide injectable BundleContext in JNDI
> ----------------------------------------
>
>                 Key: AS7-1426
>                 URL: https://issues.jboss.org/browse/AS7-1426
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: OSGi
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For: 7.1.0.Alpha1
>
>
> The system BundleContext should be available as injectable resource

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 11:08:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Thu, 28 Jul 2011 11:08:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1426) Provide injectable
 BundleContext in JNDI
In-Reply-To: <2100281757.88415.1311858383865.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <169906345.88848.1311865703666.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617307#comment-12617307 ] 

Thomas Diesler commented on AS7-1426:
-------------------------------------

This works and is ready for review
https://github.com/tdiesler/jboss-as/commit/8750bf

{code}
@Stateless
@LocalBean
public class SimpleStatelessSessionBean implements Echo {

    @Resource(lookup = "java:global/osgi/BundleContext")
    private BundleContext context;
{code}

> Provide injectable BundleContext in JNDI
> ----------------------------------------
>
>                 Key: AS7-1426
>                 URL: https://issues.jboss.org/browse/AS7-1426
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: OSGi
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For: 7.1.0.Alpha1
>
>
> The system BundleContext should be available as injectable resource

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 11:10:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Thu, 28 Jul 2011 11:10:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (AS7-1426) Provide
 injectable BundleContext in JNDI
In-Reply-To: <2100281757.88415.1311858383865.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <602650575.88859.1311865823835.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617307#comment-12617307 ] 

Thomas Diesler edited comment on AS7-1426 at 7/28/11 11:09 AM:
---------------------------------------------------------------

This works and is ready for review
https://github.com/tdiesler/jboss-as/commit/8750bfc6

{code}
@Stateless
@LocalBean
public class SimpleStatelessSessionBean implements Echo {

    @Resource(lookup = "java:global/osgi/BundleContext")
    private BundleContext context;
{code}

The BundleContext is registered like this

{code}
            // Register BundleContext in JNDI
            BinderService service = new BinderService(CONTEXT_LONG_NAME, context);
            service.getManagedObjectInjector().inject(new StaticManagedObject(context));
            ServiceBuilder<?> builder = target.addService(CONTEXT_LONG_SERVICE_NAME, service);
            builder.addDependency(CONTEXT_BASE_SERVICE_NAME, NamingStore.class, service.getNamingStoreInjector());
            builder.install();
{code}

      was (Author: thomas.diesler):
    This works and is ready for review
https://github.com/tdiesler/jboss-as/commit/8750bfc6

{code}
@Stateless
@LocalBean
public class SimpleStatelessSessionBean implements Echo {

    @Resource(lookup = "java:global/osgi/BundleContext")
    private BundleContext context;
{code}
  
> Provide injectable BundleContext in JNDI
> ----------------------------------------
>
>                 Key: AS7-1426
>                 URL: https://issues.jboss.org/browse/AS7-1426
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: OSGi
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For: 7.1.0.Alpha1
>
>
> The system BundleContext should be available as injectable resource

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 11:12:23 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Thu, 28 Jul 2011 11:12:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1426) Provide injectable
 BundleContext in JNDI
In-Reply-To: <2100281757.88415.1311858383865.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <186625210.88871.1311865943694.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617309#comment-12617309 ] 

Thomas Diesler commented on AS7-1426:
-------------------------------------

What do I need to do to get 

{code}
@Stateless
@LocalBean
public class SimpleStatelessSessionBean implements Echo {

    @Resource
    private BundleContext context;
{code}

to work (i.e. lookup by type). 

> Provide injectable BundleContext in JNDI
> ----------------------------------------
>
>                 Key: AS7-1426
>                 URL: https://issues.jboss.org/browse/AS7-1426
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: OSGi
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For: 7.1.0.Alpha1
>
>
> The system BundleContext should be available as injectable resource

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 11:16:24 2011
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Thu, 28 Jul 2011 11:16:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1425) Cannot obtain
 SchemaFactory when TCCL points to ARQ module
In-Reply-To: <1996596758.88038.1311852023607.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1681834801.88902.1311866184610.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617312#comment-12617312 ] 

Thomas Diesler commented on AS7-1425:
-------------------------------------

The tests in AS1424TestCase are ignored. 

> Cannot obtain SchemaFactory when TCCL points to ARQ module
> ----------------------------------------------------------
>
>                 Key: AS7-1425
>                 URL: https://issues.jboss.org/browse/AS7-1425
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: OSGi
>            Reporter: Thomas Diesler
>            Assignee: David Lloyd
>             Fix For: 7.1.0.Alpha1
>
>
> {code}
> testSchemaFactoryDefaultTCCL(org.jboss.as.testsuite.integration.osgi.as1424.AS1424TestCase)  Time elapsed: 0.455 sec  <<< ERROR!
> java.lang.IllegalArgumentException: No SchemaFactory that implements the schema language specified by: http://www.w3.org/2001/XMLSchema could be loaded
> 	at javax.xml.validation.SchemaFactory.newInstance(SchemaFactory.java:207)
> 	at org.jboss.as.testsuite.integration.osgi.as1424.AS1424TestCase.testSchemaFactoryDefaultTCCL(AS1424TestCase.java:74)
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 11:24:23 2011
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Thu, 28 Jul 2011 11:24:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3158) Add ability to
 support entry point declaration and compile time checking of used entry
 points
Message-ID: <1675787964.88934.1311866663667.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Add ability to support entry point declaration and compile time checking of used entry points
---------------------------------------------------------------------------------------------

                 Key: JBRULES-3158
                 URL: https://issues.jboss.org/browse/JBRULES-3158
             Project: Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-api, drools-compiler, drools-core
    Affects Versions: 5.2.0.Final
            Reporter: Edson Tirelli
            Assignee: Edson Tirelli
             Fix For: 5.3.0.Beta1


Add ability to support entry point declaration and compile time checking of used entry points. E.g.

declare entry-point A, B, C



--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 12:35:23 2011
From: jira-events at lists.jboss.org (Dennis Reed (JIRA))
Date: Thu, 28 Jul 2011 12:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-270) Intermittent
 failure of undeploy
In-Reply-To: <199739023.3169.1299196425630.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1076964926.89211.1311870923714.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBDEPLOY-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617333#comment-12617333 ] 

Dennis Reed commented on JBDEPLOY-270:
--------------------------------------

Hot-deploy the attached descriptor several times in EAP 5.0.1 and you'll see it happen.

With logging added in org.jboss.beans.metadata.plugins.AbstractBeanMetaData#setName.
When deploying it may register:
    dennis$defaultEvictionRegionConfig#1
    dennis#2
    dennis$evictionConfig#3

Then while undeploying, unregister:
    dennis#1
    dennis$defaultEvictionRegionConfig#2
    dennis$evictionConfig#3

(leaving dennis$defaultEvictionRegionConfig#1 and dennis#2 registered)
So the next time it deploys, if it tries to register one of these, it gets the exception.

Doing some further testing in different versions, while it's simple to reproduce in EAP 5.0 and 5.0.1,
I'm unable to reproduce the exception in EAP 5.1 or 5.1.1.
(The components are still getting assigned different names during deploy and undeploy, but the 
"Unable to register deployment mbean" exception is not being thrown).

Was there a related change made in EAP 5.1?

> Intermittent failure of undeploy
> --------------------------------
>
>                 Key: JBDEPLOY-270
>                 URL: https://issues.jboss.org/browse/JBDEPLOY-270
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions:  JBDEPLOY-2.0.10.GA 
>            Reporter: Dennis Reed
>         Attachments: JBDEPLOY-270-jboss-beans.xml
>
>
> When components are deployed, they are assigned names with a number appended based on the order it was processed.
> For example "jboss.deployment:id="dennis$defaultEvictionRegionConfig#1",type=Component"
> The number is assigned in (line #'s are from EAP 5.0):
>     at org.jboss.beans.metadata.plugins.AbstractBeanMetaData.setName(AbstractBeanMetaData.java:360)
>     at org.jboss.beans.metadata.plugins.NestedBeanHandler.checkForNestedBeans(NestedBeanHandler.java:77)
>     at org.jboss.beans.metadata.plugins.AbstractBeanMetaData.getBeans(AbstractBeanMetaData.java:202)
>     at org.jboss.kernel.plugins.deployment.AbstractKernelDeployment.getBeans(AbstractKernelDeployment.java:233)
>     at org.jboss.deployers.vfs.deployer.kernel.KernelDeploymentDeployer$KernelDeploymentVisitor.getBeans(KernelDeploymentDeployer.java:63)
>     at org.jboss.deployers.vfs.deployer.kernel.KernelDeploymentDeployer$KernelDeploymentVisitor.getBeans(KernelDeploymentDeployer.java:54)
>     at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryVisitor.deploy(BeanMetaDataFactoryVisitor.java:118)
> However, the beans are *not* processed in the same order every time.
> And they are processed separately during deployment and undeployment.
> This means that "myBean#1" may get deployed, but "myBean#2" is undeployed (leaving "myBean#1" still deployed).
> Subsequent deployments will fail with errors:
> 17:34:30,630 WARN  [AbstractDeploymentContext] Unable to register deployment mbean dennis$defaultEvictionRegionConfig#1
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="dennis$defaultEvictionRegionConfig#1",type=Component already registered.
> The root cause appears to be that the XML descriptor is read with jboss-xb using a Set (unordered), but then 
> this code has a dependency on the order being consistent between deploy and undeploy.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 13:34:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 28 Jul 2011 13:34:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJCA-638) ActivationSpec
 config-property map not updated with introspected properties
Message-ID: <603971758.89344.1311874463862.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

ActivationSpec config-property map not updated with introspected properties
---------------------------------------------------------------------------

                 Key: JBJCA-638
                 URL: https://issues.jboss.org/browse/JBJCA-638
             Project: IronJacamar
          Issue Type: Bug
          Components: Core
    Affects Versions: 1.0.1.Final
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
            Priority: Critical
             Fix For: 1.0.2.Final, 1.1.0.Alpha1


The config-property map for an Activation isn't updated with the introspected types from the ActivationSpec class.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 13:38:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 28 Jul 2011 13:38:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-638) ActivationSpec
 config-property map not updated with introspected properties
In-Reply-To: <603971758.89344.1311874463862.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1085062.89355.1311874703620.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-638.
-----------------------------------

    Resolution: Done


> ActivationSpec config-property map not updated with introspected properties
> ---------------------------------------------------------------------------
>
>                 Key: JBJCA-638
>                 URL: https://issues.jboss.org/browse/JBJCA-638
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.1.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.2.Final, 1.1.0.Alpha1
>
>
> The config-property map for an Activation isn't updated with the introspected types from the ActivationSpec class.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 14:36:23 2011
From: jira-events at lists.jboss.org (Federico Weisse (JIRA))
Date: Thu, 28 Jul 2011 14:36:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3159) Exception throw
 when Dynamic Kbase updates occurs in Fusion temporal rules
Message-ID: <343727718.89545.1311878183967.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Exception throw when Dynamic Kbase updates occurs in Fusion temporal rules
--------------------------------------------------------------------------

                 Key: JBRULES-3159
                 URL: https://issues.jboss.org/browse/JBRULES-3159
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Federico Weisse
            Assignee: Mark Proctor


when a dynamic changes occurs in KBase an exception is trhow

011-07-28 13:14:21,703 INFO  [STDOUT] [2011:07:209 13:07:703:debug] ResourceChangeScanner attempt to scan 1 resources
2011-07-28 13:14:21,703 INFO  [STDOUT] [2011:07:209 13:07:703:debug] ResourceChangeScanner modified resource=[UrlResource path='file:f://usr//bin//jboss-4.3//server//osdeweb//conf//drools//urgencias.drl'] : 1311869325187 : 1311869473656
2011-07-28 13:14:21,703 INFO  [STDOUT] [2011:07:209 13:07:703:debug] ResourceChangeNotification received ChangeSet notification
2011-07-28 13:14:21,703 INFO  [STDOUT] [2011:07:209 13:07:703:debug] ResourceChangeScanner thread is waiting for 300 seconds.
2011-07-28 13:14:21,703 INFO  [STDOUT] [2011:07:209 13:07:703:debug] ResourceChangeNotification processing ChangeSet
2011-07-28 13:14:21,703 INFO  [STDOUT] [2011:07:209 13:07:703:debug] ResourceChangeNotification ChangeSet modified resource=[UrlResource path='file:f://usr//bin//jboss-4.3//server//osdeweb//conf//drools//urgencias.drl'] for listener=org.drools.agent.impl.KnowledgeAgentImpl at eaa827
2011-07-28 13:14:21,703 INFO  [STDOUT] [2011:07:209 13:07:703:debug] KnowledgeAgent received ChangeSet changed notification
2011-07-28 13:14:21,703 INFO  [STDOUT] [2011:07:209 13:07:703:debug] ResourceChangeNotification thread is waiting for queue update
2011-07-28 13:14:21,703 INFO  [STDOUT] [2011:07:209 13:07:703:info] KnowledgeAgent applying ChangeSet
2011-07-28 13:14:21,703 INFO  [STDOUT] [2011:07:209 13:07:703:debug] KnowledgeAgent removing mappings for resource=[UrlResource path='file:f://usr//bin//jboss-4.3//server//osdeweb//conf//drools//urgencias.drl'] with unsubscribe=true
2011-07-28 13:14:21,703 INFO  [STDOUT] [2011:07:209 13:07:703:debug] KnowledgeAgent notifier unsubscribing to resource=[UrlResource path='file:f://usr//bin//jboss-4.3//server//osdeweb//conf//drools//urgencias.drl']
2011-07-28 13:14:21,703 INFO  [STDOUT] [2011:07:209 13:07:703:debug] ResourceChangeNotification unsubscribing listener=org.drools.agent.impl.KnowledgeAgentImpl at eaa827 to resource=[UrlResource path='file:f://usr//bin//jboss-4.3//server//osdeweb//conf//drools//urgencias.drl']
2011-07-28 13:14:21,703 INFO  [STDOUT] [2011:07:209 13:07:703:debug] ResourceChangeScanner unsubcribing notifier=org.drools.io.impl.ResourceChangeNotifierImpl at c69727 to resource=[UrlResource path='file:f://usr//bin//jboss-4.3//server//osdeweb//conf//drools//urgencias.drl']
2011-07-28 13:14:21,703 INFO  [STDOUT] [2011:07:209 13:07:703:debug] ResourceChangeScanner resource=[UrlResource path='file:f://usr//bin//jboss-4.3//server//osdeweb//conf//drools//urgencias.drl'] now has no subscribers
2011-07-28 13:14:21,703 INFO  [STDOUT] [2011:07:209 13:07:703:debug] KnowledgeAgent rebuilding KnowledgeBase using ChangeSet
2011-07-28 13:14:21,703 INFO  [STDOUT] [2011:07:209 13:07:703:info] KnowledgeAgent performing an incremental build of the ChangeSet
2011-07-28 13:14:22,218 INFO  [STDOUT] [2011:07:209 13:07:218:debug] KnowledgeAgent: Diffing: [UrlResource path='file:f://usr//bin//jboss-4.3//server//osdeweb//conf//drools//urgencias.drl']
2011-07-28 13:14:22,218 INFO  [STDOUT] [2011:07:209 13:07:218:debug] BinaryResourceDiffProducerImpl: Couldn't handle org.drools.rule.TypeDeclaration at 6bdc57. We must leave it in the new Package.
2011-07-28 13:14:22,218 INFO  [STDOUT] [2011:07:209 13:07:218:debug] BinaryResourceDiffProducerImpl: Comparing [Rule name=Mas de 20 codigos rojos en el mismo barrio, agendaGroup=MAIN, salience=0, no-loop=false] against [Rule name=Mas de 20 codigos rojos en el mismo barrio, agendaGroup=MAIN, salience=0, no-loop=false]
2011-07-28 13:14:22,218 INFO  [STDOUT] [2011:07:209 13:07:218:debug] BinaryResourceDiffProducerImpl: The rules have different LHS
2011-07-28 13:14:22,218 INFO  [STDOUT] [2011:07:209 13:07:218:debug] BinaryResourceDiffProducerImpl: Comparing [Rule name=urgencia codigo amarillo pendiente por mas de 3 minutos, agendaGroup=MAIN, salience=0, no-loop=false] against [Rule name=urgencia codigo amarillo pendiente por mas de 3 minutos, agendaGroup=MAIN, salience=0, no-loop=false]
2011-07-28 13:14:22,218 INFO  [STDOUT] [2011:07:209 13:07:218:debug] BinaryResourceDiffProducerImpl: The rules have different LHS
2011-07-28 13:14:22,218 INFO  [STDOUT] [2011:07:209 13:07:218:debug] BinaryResourceDiffProducerImpl: Comparing [Rule name=urgencia codigo rojo pendiente por mas de 10 minutos, agendaGroup=MAIN, salience=0, no-loop=false] against [Rule name=urgencia codigo rojo pendiente por mas de 10 minutos, agendaGroup=MAIN, salience=0, no-loop=false]
2011-07-28 13:14:22,218 INFO  [STDOUT] [2011:07:209 13:07:218:debug] BinaryResourceDiffProducerImpl: The rules have different LHS
2011-07-28 13:14:22,218 INFO  [STDOUT] [2011:07:209 13:07:218:debug] KnowledgeAgent obtaining pkg resource=[UrlResource path='file:f://usr//bin//jboss-4.3//server//osdeweb//conf//drools//urgencias.drl']
2011-07-28 13:14:22,218 INFO  [STDOUT] [2011:07:209 13:07:218:debug] KnowledgeAgent mapping resource=[UrlResource path='file:f://usr//bin//jboss-4.3//server//osdeweb//conf//drools//urgencias.drl'] to KnowledgeDefinition=[Rule name=Mas de 20 codigos rojos en el mismo barrio, agendaGroup=MAIN, salience=0, no-loop=false]
2011-07-28 13:14:22,218 INFO  [STDOUT] [2011:07:209 13:07:218:debug] KnowledgeAgent notifier subscribing to resource=[UrlResource path='file:f://usr//bin//jboss-4.3//server//osdeweb//conf//drools//urgencias.drl']
2011-07-28 13:14:22,218 INFO  [STDOUT] [2011:07:209 13:07:218:debug] ResourceChangeNotification subscribing listener=org.drools.agent.impl.KnowledgeAgentImpl at eaa827 to resource=[UrlResource path='file:f://usr//bin//jboss-4.3//server//osdeweb//conf//drools//urgencias.drl']
2011-07-28 13:14:22,218 INFO  [STDOUT] [2011:07:209 13:07:218:debug] ResourceChangeScanner subcribing notifier=org.drools.io.impl.ResourceChangeNotifierImpl at c69727 to resource=[UrlResource path='file:f://usr//bin//jboss-4.3//server//osdeweb//conf//drools//urgencias.drl']
2011-07-28 13:14:22,218 INFO  [STDOUT] [2011:07:209 13:07:218:debug] KnowledgeAgent mapping resource=[UrlResource path='file:f://usr//bin//jboss-4.3//server//osdeweb//conf//drools//urgencias.drl'] to KnowledgeDefinition=[Rule name=urgencia codigo rojo pendiente por mas de 10 minutos, agendaGroup=MAIN, salience=0, no-loop=false]
2011-07-28 13:14:22,218 INFO  [STDOUT] [2011:07:209 13:07:218:debug] KnowledgeAgent notifier subscribing to resource=[UrlResource path='file:f://usr//bin//jboss-4.3//server//osdeweb//conf//drools//urgencias.drl']
2011-07-28 13:14:22,218 INFO  [STDOUT] [2011:07:209 13:07:218:debug] ResourceChangeNotification subscribing listener=org.drools.agent.impl.KnowledgeAgentImpl at eaa827 to resource=[UrlResource path='file:f://usr//bin//jboss-4.3//server//osdeweb//conf//drools//urgencias.drl']
2011-07-28 13:14:22,218 INFO  [STDOUT] [2011:07:209 13:07:218:debug] KnowledgeAgent mapping resource=[UrlResource path='file:f://usr//bin//jboss-4.3//server//osdeweb//conf//drools//urgencias.drl'] to KnowledgeDefinition=[Rule name=urgencia codigo amarillo pendiente por mas de 3 minutos, agendaGroup=MAIN, salience=0, no-loop=false]
2011-07-28 13:14:22,218 INFO  [STDOUT] [2011:07:209 13:07:218:debug] KnowledgeAgent notifier subscribing to resource=[UrlResource path='file:f://usr//bin//jboss-4.3//server//osdeweb//conf//drools//urgencias.drl']
2011-07-28 13:14:22,218 INFO  [STDOUT] [2011:07:209 13:07:218:debug] ResourceChangeNotification subscribing listener=org.drools.agent.impl.KnowledgeAgentImpl at eaa827 to resource=[UrlResource path='file:f://usr//bin//jboss-4.3//server//osdeweb//conf//drools//urgencias.drl']
2011-07-28 13:14:22,218 INFO  [STDOUT] [2011:07:209 13:07:218:debug] KnowledgeAgent mapping resource=[UrlResource path='file:f://usr//bin//jboss-4.3//server//osdeweb//conf//drools//urgencias.drl'] to KnowledgeDefinition=org.drools.rule.TypeDeclaration at 1e3a6dd
2011-07-28 13:14:22,218 INFO  [STDOUT] [2011:07:209 13:07:218:debug] KnowledgeAgent notifier subscribing to resource=[UrlResource path='file:f://usr//bin//jboss-4.3//server//osdeweb//conf//drools//urgencias.drl']
2011-07-28 13:14:22,218 INFO  [STDOUT] [2011:07:209 13:07:218:debug] ResourceChangeNotification subscribing listener=org.drools.agent.impl.KnowledgeAgentImpl at eaa827 to resource=[UrlResource path='file:f://usr//bin//jboss-4.3//server//osdeweb//conf//drools//urgencias.drl']
2011-07-28 13:14:22,218 INFO  [STDOUT] [2011:07:209 13:07:218:debug] KnowledgeAgent adding KnowledgeDefinitionsPackage ar.com.osde.urgencias
Exception in thread "Thread-18" 
 java.lang.NullPointerException
2011-07-28 13:14:22,234 ERROR [STDERR] 	at org.drools.reteoo.RightTuple.unlinkFromRightParent(RightTuple.java:107)
2011-07-28 13:14:22,234 ERROR [STDERR] 	at org.drools.reteoo.BetaNode.doRemove(BetaNode.java:282)
2011-07-28 13:14:22,234 ERROR [STDERR] 	at org.drools.common.BaseNode.remove(BaseNode.java:109)
2011-07-28 13:14:22,234 ERROR [STDERR] 	at org.drools.reteoo.BetaNode.doRemove(BetaNode.java:293)
2011-07-28 13:14:22,234 ERROR [STDERR] 	at org.drools.common.BaseNode.remove(BaseNode.java:109)
2011-07-28 13:14:22,234 ERROR [STDERR] 	at org.drools.reteoo.RuleTerminalNode.doRemove(RuleTerminalNode.java:411)
2011-07-28 13:14:22,234 ERROR [STDERR] 	at org.drools.common.BaseNode.remove(BaseNode.java:109)
2011-07-28 13:14:22,234 ERROR [STDERR] 	at org.drools.reteoo.ReteooBuilder.removeRule(ReteooBuilder.java:237)
2011-07-28 13:14:22,234 ERROR [STDERR] 	at org.drools.reteoo.ReteooRuleBase.removeRule(ReteooRuleBase.java:432)
2011-07-28 13:14:22,234 ERROR [STDERR] 	at org.drools.common.AbstractRuleBase.removeRule(AbstractRuleBase.java:831)
2011-07-28 13:14:22,234 ERROR [STDERR] 	at org.drools.common.AbstractRuleBase.mergePackage(AbstractRuleBase.java:623)
2011-07-28 13:14:22,234 ERROR [STDERR] 	at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:539)
2011-07-28 13:14:22,234 ERROR [STDERR] 	at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:445)
2011-07-28 13:14:22,234 ERROR [STDERR] 	at org.drools.reteoo.ReteooRuleBase.addPackage(ReteooRuleBase.java:452)
2011-07-28 13:14:22,234 ERROR [STDERR] 	at org.drools.agent.impl.KnowledgeAgentImpl.addResourcesToKnowledgeBase(KnowledgeAgentImpl.java:937)
2011-07-28 13:14:22,234 ERROR [STDERR] 	at org.drools.agent.impl.KnowledgeAgentImpl.incrementalBuildResources(KnowledgeAgentImpl.java:821)
2011-07-28 13:14:22,234 ERROR [STDERR] 	at org.drools.agent.impl.KnowledgeAgentImpl.buildKnowledgeBase(KnowledgeAgentImpl.java:586)
2011-07-28 13:14:22,234 ERROR [STDERR] 	at org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:185)
2011-07-28 13:14:22,234 ERROR [STDERR] 	at org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector.run(KnowledgeAgentImpl.java:1106)
2011-07-28 13:14:22,234 ERROR [STDERR] 	at java.lang.Thread.run(Thread.java:619)




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 15:39:23 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Thu, 28 Jul 2011 15:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (AS7-1365) Add configurable
 jvm-route to web subsystem to support mod_jk and mod_proxy.
In-Reply-To: <879296760.73495.1311277163672.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <631258519.89678.1311881963656.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro reopened AS7-1365:
-------------------------------



Remy,
Thinking about this more, relying on the mod_cluster subsystem to generate the jvm route won't work.  The jvm-route is only generated once an AS instance makes contact with an httpd server.  If the user is only using mod_jk or mod_proxy with mod_proxy_balancer, they probably won't have the requite mod_cluster modules installed, so the AS node would never make contact with the httpd server in the first place.  Consequently, no jvm-route will ever be auto-generated.

So, I'm going to go ahead and re-open this jira. :)

Second, even if the jvm-route auto-generation were to happen, the jvm-route is available from any subsystem model, and cannot be queried via any management mechanism (other than jmx, but I don't think that's sufficient).

> Add configurable jvm-route to web subsystem to support mod_jk and mod_proxy.
> ----------------------------------------------------------------------------
>
>                 Key: AS7-1365
>                 URL: https://issues.jboss.org/browse/AS7-1365
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Web
>    Affects Versions: 7.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Remy Maucherat
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 18:02:23 2011
From: jira-events at lists.jboss.org (Dennis Reed (JIRA))
Date: Thu, 28 Jul 2011 18:02:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-2265)
 JndiSessionRegistrarBase registers EJBs with @RemoteBinding twice
Message-ID: <845444941.90040.1311890543704.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

JndiSessionRegistrarBase registers EJBs with @RemoteBinding twice
-----------------------------------------------------------------

                 Key: EJBTHREE-2265
                 URL: https://issues.jboss.org/browse/EJBTHREE-2265
             Project: EJB 3.0
          Issue Type: Bug
          Components: proxy-impl
    Affects Versions: EJB3_1 1.0.6
            Reporter: Dennis Reed
            Assignee: Dennis Reed


JndiSessionRegistrarBase registers the EJB's ProxyFactory, then immediately unbinds and registers it again.

This causes problems in ProxyClusteringRegistry because the register call sets up a map of cluster members, which is referenced
from the EJB's ReplicantsManagerInterceptor. The unbind then deletes this map in ProxyClusteringRegistry, and the 2nd
register creates a new map that will get updates when the cluster membership changes.
Since the interceptor now has a reference to a different map, it never sees the cluster membership changes.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 19:44:23 2011
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Thu, 28 Jul 2011 19:44:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-9425) Upgrade to
	hibernate 3.6.6-Final
In-Reply-To: <808838393.88519.1311860843825.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1534927984.90122.1311896663633.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBAS-9425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan resolved JBAS-9425.
----------------------------------

    Resolution: Done


Resolved and no regressions seen in TCK testing.

> Upgrade to hibernate 3.6.6-Final
> --------------------------------
>
>                 Key: JBAS-9425
>                 URL: https://issues.jboss.org/browse/JBAS-9425
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JPA / Hibernate
>            Reporter: Strong Liu
>            Assignee: Strong Liu
>             Fix For: 6.1.0
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 19:54:23 2011
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Thu, 28 Jul 2011 19:54:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-9426) org.jboss.jmx.test
	regressions
Message-ID: <531214594.90125.1311897263620.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

org.jboss.jmx.test regressions
------------------------------

                 Key: JBAS-9426
                 URL: https://issues.jboss.org/browse/JBAS-9426
             Project: Legacy JBoss Application Server 6 
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: JMX
            Reporter: Shelly McGowan
             Fix For: 6.1.0




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 19:56:23 2011
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Thu, 28 Jul 2011 19:56:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-9426) org.jboss.jmx.test
	regressions
In-Reply-To: <531214594.90125.1311897263620.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1202704305.90128.1311897383637.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBAS-9426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-9426:
---------------------------------

    Description: 
Tests affected:
org.jboss.test.jmx.test.JMXConnectorUnitTestCase
org.jboss.test.jmx.test.JMXInvokerUnitTestCase
org.jboss.test.jmx.test.SecureJMXInvokerUnitTestCase


> org.jboss.jmx.test regressions
> ------------------------------
>
>                 Key: JBAS-9426
>                 URL: https://issues.jboss.org/browse/JBAS-9426
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>            Reporter: Shelly McGowan
>             Fix For: 6.1.0
>
>
> Tests affected:
> org.jboss.test.jmx.test.JMXConnectorUnitTestCase
> org.jboss.test.jmx.test.JMXInvokerUnitTestCase
> org.jboss.test.jmx.test.SecureJMXInvokerUnitTestCase

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 19:58:23 2011
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Thu, 28 Jul 2011 19:58:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-9427)
 org.jboss.test.jbossmessaging.test.XAResourceUnitTestCase
Message-ID: <396564517.90132.1311897503674.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

org.jboss.test.jbossmessaging.test.XAResourceUnitTestCase
---------------------------------------------------------

                 Key: JBAS-9427
                 URL: https://issues.jboss.org/browse/JBAS-9427
             Project: Legacy JBoss Application Server 6 
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: JMS (HornetQ)
            Reporter: Shelly McGowan
            Assignee: Shelly McGowan
             Fix For: 6.1.0


Tests affected:
org.jboss.test.jbossmessaging.test.XAResourceUnitTestCase

These tests have been failing for a while since the last HornetQ upgrade and IIRC is a test configuration issue.  I'll confirm.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 19:58:23 2011
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Thu, 28 Jul 2011 19:58:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-9427)
 org.jboss.test.jbossmessaging.test.XAResourceUnitTestCase
In-Reply-To: <396564517.90132.1311897503674.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1066439824.90134.1311897503747.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBAS-9427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617416#comment-12617416 ] 

Shelly McGowan commented on JBAS-9427:
--------------------------------------

java.lang.ClassCastException: org.hornetq.jms.client.HornetQJMSConnectionFactory cannot be cast to javax.jms.XATopicConnectionFactory
	at org.jboss.test.jbossmessaging.test.XAResourceUnitTestCase.testXAResourceSuspendWorkCommit(XAResourceUnitTestCase.java:76)


> org.jboss.test.jbossmessaging.test.XAResourceUnitTestCase
> ---------------------------------------------------------
>
>                 Key: JBAS-9427
>                 URL: https://issues.jboss.org/browse/JBAS-9427
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS (HornetQ)
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: 6.1.0
>
>
> Tests affected:
> org.jboss.test.jbossmessaging.test.XAResourceUnitTestCase
> These tests have been failing for a while since the last HornetQ upgrade and IIRC is a test configuration issue.  I'll confirm.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 20:02:23 2011
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Thu, 28 Jul 2011 20:02:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-9428)
 org.jboss.test.jca.test.DataSourceDeployerTestCase - JTS
Message-ID: <1048743586.90138.1311897743788.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

org.jboss.test.jca.test.DataSourceDeployerTestCase - JTS
--------------------------------------------------------

                 Key: JBAS-9428
                 URL: https://issues.jboss.org/browse/JBAS-9428
             Project: Legacy JBoss Application Server 6 
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Shelly McGowan


testBasicDeployment:
javax.management.InstanceNotFoundException: jboss.jca:name=DSEARXML,service=ManagedConnectionFactory is not registered.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 21:52:24 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 28 Jul 2011 21:52:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-474) EJB Timers
In-Reply-To: <1296631015.31393.1300323843041.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1499219444.90214.1311904344434.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned AS7-474:
----------------------------------

    Assignee: Stuart Douglas


> EJB Timers
> ----------
>
>                 Key: AS7-474
>                 URL: https://issues.jboss.org/browse/AS7-474
>             Project: Application Server 7
>          Issue Type: Task
>          Components: EJB
>            Reporter: David Lloyd
>            Assignee: Stuart Douglas
>             Fix For: 7.1.0.Alpha1
>
>
> Parent task for EJB Timer implementation items.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 21:54:23 2011
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 28 Jul 2011 21:54:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-474) EJB Timers
In-Reply-To: <1296631015.31393.1300323843041.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1891698875.90230.1311904463700.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617423#comment-12617423 ] 

Stuart Douglas commented on AS7-474:
------------------------------------

Management Features that should be supported include:

pause/resume
force timeout
change timing
metrics 

> EJB Timers
> ----------
>
>                 Key: AS7-474
>                 URL: https://issues.jboss.org/browse/AS7-474
>             Project: Application Server 7
>          Issue Type: Task
>          Components: EJB
>            Reporter: David Lloyd
>            Assignee: Stuart Douglas
>             Fix For: 7.1.0.Alpha1
>
>
> Parent task for EJB Timer implementation items.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Thu Jul 28 23:44:23 2011
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Thu, 28 Jul 2011 23:44:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1397) JPS executable not
	found
In-Reply-To: <1625953177.81023.1311628463845.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1894535945.90268.1311911063611.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins resolved AS7-1397.
--------------------------------

    Fix Version/s: 7.0.1.Final
                       (was: 7.1.0.Alpha1)
       Resolution: Done


> JPS executable not found
> ------------------------
>
>                 Key: AS7-1397
>                 URL: https://issues.jboss.org/browse/AS7-1397
>             Project: Application Server 7
>          Issue Type: Bug
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 7.0.1.Final
>
>
> org.jboss.as.test.integration.respawn.RespawnTestCase: java.io.IOException: Cannot run program "/usr/java/jdk1.6.0_26/jre/bin/jps": java.io.IOException: error=2, No such file or directory.
> The JPS executable does not appear to be located in the JRE home.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 05:47:23 2011
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Fri, 29 Jul 2011 05:47:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-270) Intermittent
 failure of undeploy
In-Reply-To: <199739023.3169.1299196425630.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <970982014.90872.1311932843791.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBDEPLOY-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617481#comment-12617481 ] 

Ales Justin commented on JBDEPLOY-270:
--------------------------------------

>> Was there a related change made in EAP 5.1?

EAP 5.1 disabled deployment MBean registry (see deployers.xml):

   <!-- Uncomment the following @org.jboss.aop.microcontainer.aspects.jmx.JMX to enable registering
    MC beans as MBeans. These MBeans provide debug level information about which deployers were selected for
    processing the deployment and what attachments were added to the deployment. More details http://www.jboss.org/index.html?module=bb&op=viewtopic&t=155074&start=10#4233874
    -->



> Intermittent failure of undeploy
> --------------------------------
>
>                 Key: JBDEPLOY-270
>                 URL: https://issues.jboss.org/browse/JBDEPLOY-270
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions:  JBDEPLOY-2.0.10.GA 
>            Reporter: Dennis Reed
>         Attachments: JBDEPLOY-270-jboss-beans.xml
>
>
> When components are deployed, they are assigned names with a number appended based on the order it was processed.
> For example "jboss.deployment:id="dennis$defaultEvictionRegionConfig#1",type=Component"
> The number is assigned in (line #'s are from EAP 5.0):
>     at org.jboss.beans.metadata.plugins.AbstractBeanMetaData.setName(AbstractBeanMetaData.java:360)
>     at org.jboss.beans.metadata.plugins.NestedBeanHandler.checkForNestedBeans(NestedBeanHandler.java:77)
>     at org.jboss.beans.metadata.plugins.AbstractBeanMetaData.getBeans(AbstractBeanMetaData.java:202)
>     at org.jboss.kernel.plugins.deployment.AbstractKernelDeployment.getBeans(AbstractKernelDeployment.java:233)
>     at org.jboss.deployers.vfs.deployer.kernel.KernelDeploymentDeployer$KernelDeploymentVisitor.getBeans(KernelDeploymentDeployer.java:63)
>     at org.jboss.deployers.vfs.deployer.kernel.KernelDeploymentDeployer$KernelDeploymentVisitor.getBeans(KernelDeploymentDeployer.java:54)
>     at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryVisitor.deploy(BeanMetaDataFactoryVisitor.java:118)
> However, the beans are *not* processed in the same order every time.
> And they are processed separately during deployment and undeployment.
> This means that "myBean#1" may get deployed, but "myBean#2" is undeployed (leaving "myBean#1" still deployed).
> Subsequent deployments will fail with errors:
> 17:34:30,630 WARN  [AbstractDeploymentContext] Unable to register deployment mbean dennis$defaultEvictionRegionConfig#1
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="dennis$defaultEvictionRegionConfig#1",type=Component already registered.
> The root cause appears to be that the XML descriptor is read with jboss-xb using a Set (unordered), but then 
> this code has a dependency on the order being consistent between deploy and undeploy.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 06:08:23 2011
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Fri, 29 Jul 2011 06:08:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBDEPLOY-270) Intermittent
 failure of undeploy
In-Reply-To: <199739023.3169.1299196425630.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <93921766.90912.1311934103894.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBDEPLOY-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617487#comment-12617487 ] 

Ales Justin commented on JBDEPLOY-270:
--------------------------------------

OK, I see what the real problem is.
It's how AbstractBeanMetaData handles NestedBeanHandler.
It goes and re-creates a new nested bean list on every getBean invocation.
Where MetaDataVisitorNode uses set to order metadata children, hence PropertyMetaData is randomly ordered --> diff counter number.

Caching AbstractBeanMetaData::getBeans would probably fix this problem.


> Intermittent failure of undeploy
> --------------------------------
>
>                 Key: JBDEPLOY-270
>                 URL: https://issues.jboss.org/browse/JBDEPLOY-270
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions:  JBDEPLOY-2.0.10.GA 
>            Reporter: Dennis Reed
>         Attachments: JBDEPLOY-270-jboss-beans.xml
>
>
> When components are deployed, they are assigned names with a number appended based on the order it was processed.
> For example "jboss.deployment:id="dennis$defaultEvictionRegionConfig#1",type=Component"
> The number is assigned in (line #'s are from EAP 5.0):
>     at org.jboss.beans.metadata.plugins.AbstractBeanMetaData.setName(AbstractBeanMetaData.java:360)
>     at org.jboss.beans.metadata.plugins.NestedBeanHandler.checkForNestedBeans(NestedBeanHandler.java:77)
>     at org.jboss.beans.metadata.plugins.AbstractBeanMetaData.getBeans(AbstractBeanMetaData.java:202)
>     at org.jboss.kernel.plugins.deployment.AbstractKernelDeployment.getBeans(AbstractKernelDeployment.java:233)
>     at org.jboss.deployers.vfs.deployer.kernel.KernelDeploymentDeployer$KernelDeploymentVisitor.getBeans(KernelDeploymentDeployer.java:63)
>     at org.jboss.deployers.vfs.deployer.kernel.KernelDeploymentDeployer$KernelDeploymentVisitor.getBeans(KernelDeploymentDeployer.java:54)
>     at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryVisitor.deploy(BeanMetaDataFactoryVisitor.java:118)
> However, the beans are *not* processed in the same order every time.
> And they are processed separately during deployment and undeployment.
> This means that "myBean#1" may get deployed, but "myBean#2" is undeployed (leaving "myBean#1" still deployed).
> Subsequent deployments will fail with errors:
> 17:34:30,630 WARN  [AbstractDeploymentContext] Unable to register deployment mbean dennis$defaultEvictionRegionConfig#1
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="dennis$defaultEvictionRegionConfig#1",type=Component already registered.
> The root cause appears to be that the XML descriptor is read with jboss-xb using a Set (unordered), but then 
> this code has a dependency on the order being consistent between deploy and undeploy.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 06:13:23 2011
From: jira-events at lists.jboss.org (Ales Justin (JIRA))
Date: Fri, 29 Jul 2011 06:13:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBDEPLOY-270) Intermittent
 failure of undeploy
In-Reply-To: <199739023.3169.1299196425630.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <998261298.90919.1311934403652.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBDEPLOY-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ales Justin reassigned JBDEPLOY-270:
------------------------------------

    Assignee: Ales Justin


> Intermittent failure of undeploy
> --------------------------------
>
>                 Key: JBDEPLOY-270
>                 URL: https://issues.jboss.org/browse/JBDEPLOY-270
>             Project: JBoss Deployers
>          Issue Type: Bug
>          Components: deployer
>    Affects Versions:  JBDEPLOY-2.0.10.GA 
>            Reporter: Dennis Reed
>            Assignee: Ales Justin
>         Attachments: JBDEPLOY-270-jboss-beans.xml
>
>
> When components are deployed, they are assigned names with a number appended based on the order it was processed.
> For example "jboss.deployment:id="dennis$defaultEvictionRegionConfig#1",type=Component"
> The number is assigned in (line #'s are from EAP 5.0):
>     at org.jboss.beans.metadata.plugins.AbstractBeanMetaData.setName(AbstractBeanMetaData.java:360)
>     at org.jboss.beans.metadata.plugins.NestedBeanHandler.checkForNestedBeans(NestedBeanHandler.java:77)
>     at org.jboss.beans.metadata.plugins.AbstractBeanMetaData.getBeans(AbstractBeanMetaData.java:202)
>     at org.jboss.kernel.plugins.deployment.AbstractKernelDeployment.getBeans(AbstractKernelDeployment.java:233)
>     at org.jboss.deployers.vfs.deployer.kernel.KernelDeploymentDeployer$KernelDeploymentVisitor.getBeans(KernelDeploymentDeployer.java:63)
>     at org.jboss.deployers.vfs.deployer.kernel.KernelDeploymentDeployer$KernelDeploymentVisitor.getBeans(KernelDeploymentDeployer.java:54)
>     at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataFactoryVisitor.deploy(BeanMetaDataFactoryVisitor.java:118)
> However, the beans are *not* processed in the same order every time.
> And they are processed separately during deployment and undeployment.
> This means that "myBean#1" may get deployed, but "myBean#2" is undeployed (leaving "myBean#1" still deployed).
> Subsequent deployments will fail with errors:
> 17:34:30,630 WARN  [AbstractDeploymentContext] Unable to register deployment mbean dennis$defaultEvictionRegionConfig#1
> javax.management.InstanceAlreadyExistsException: jboss.deployment:id="dennis$defaultEvictionRegionConfig#1",type=Component already registered.
> The root cause appears to be that the XML descriptor is read with jboss-xb using a Set (unordered), but then 
> this code has a dependency on the order being consistent between deploy and undeploy.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 07:19:24 2011
From: jira-events at lists.jboss.org (David Bosschaert (JIRA))
Date: Fri, 29 Jul 2011 07:19:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-932) Expose runtime OSGi
 Bundle management through management API
In-Reply-To: <1120411091.39582.1306923361337.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1666376714.91192.1311938364113.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Bosschaert updated AS7-932:
---------------------------------

    Priority: Minor  (was: Major)


> Expose runtime OSGi Bundle management through management API
> ------------------------------------------------------------
>
>                 Key: AS7-932
>                 URL: https://issues.jboss.org/browse/AS7-932
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: OSGi
>    Affects Versions: 7.0.0.CR1
>            Reporter: David Bosschaert
>            Assignee: David Bosschaert
>            Priority: Minor
>             Fix For: 7.1.0.CR1
>
>
> Bundle runtime management should be exposed through the management API.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 07:19:24 2011
From: jira-events at lists.jboss.org (David Bosschaert (JIRA))
Date: Fri, 29 Jul 2011 07:19:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1410) Expose runtime OSGi
 management configuration through console
In-Reply-To: <145027417.84077.1311754943682.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1797109780.91211.1311938364556.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Bosschaert updated AS7-1410:
----------------------------------

    Priority: Minor  (was: Major)


> Expose runtime OSGi management configuration through console
> ------------------------------------------------------------
>
>                 Key: AS7-1410
>                 URL: https://issues.jboss.org/browse/AS7-1410
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: Console
>            Reporter: David Bosschaert
>            Assignee: David Bosschaert
>            Priority: Minor
>             Fix For: 7.1.0.CR1
>
>
> Bundle runtime management should be exposed through the console.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 07:46:23 2011
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 29 Jul 2011 07:46:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2700) Allow setting a
 global variable (for example a service) which can be used by the score
 rules
In-Reply-To: <401582676.7221.1284738748577.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1725450980.91285.1311939983919.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617511#comment-12617511 ] 

Geoffrey De Smet commented on JBRULES-2700:
-------------------------------------------

Similar discussion with a workaround: http://stackoverflow.com/questions/6625000/drools-creating-a-custom-score



> Allow setting a global variable (for example a service) which can be used by the score rules
> --------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2700
>                 URL: https://issues.jboss.org/browse/JBRULES-2700
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-planner
>            Reporter: Wouter Horr?
>            Assignee: Geoffrey De Smet
>
> Currently, it is not possible to set a global variable in the working memory used by the solver. If a scoring rule needs an external helper for calculating scores (e.g. a dependency injected with OSGi DS), a workaround using a static variable in some class accessible by the scoring rules is needed.
> The easiest implementation is probably a new method in the Solver interface:
> public WorkingMemory getWorkingMemory();
> which provides access to the working memory used by the solver.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Fri Jul 29 07:46:24 2011
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 29 Jul 2011 07:46:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (JBRULES-2700)
 Allow setting a global variable (for example a service) which can be used
 by the score rules
In-Reply-To: <401582676.7221.1284738748577.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <531373522.91288.1311939984007.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12551639#comment-12551639 ] 

Geoffrey De Smet edited comment on JBRULES-2700 at 7/29/11 7:44 AM:
--------------------------------------------------------------------

For another issue, it should be possible to set the RuleBase instead of supplying the DRL references.
Would that solve this issue? Maybe not because a service needs to be set on the WM, not the RuleBase which creates the WM.
Update: It would not solve this issue because setting it on the rulebase doesn't work, because global variables need to be set on the WorkingMemory instances, not the RuleBase.

However, every now and then planner needs to create a new WM (especially once we go multi-threaded/vm), currently only in debug mode I believe, so setting it on an individual WM isn't a good solution.
Defining a map of globals to put on any WM that is created, might work.

      was (Author: ge0ffrey):
    For another issue, it should be possible to set the RuleBase instead of supplying the DRL references.
Would that solve this issue? Maybe not because a service needs to be set on the WM, not the RuleBase which creates the WM.

However, every now and then planner needs to create a new WM (especially once we go multi-threaded/vm), currently only in debug mode I believe, so setting it on an individual WM isn't a good solution.
Defining a map of globals to put on any WM that is created, might work.
  
> Allow setting a global variable (for example a service) which can be used by the score rules
> --------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2700
>                 URL: https://issues.jboss.org/browse/JBRULES-2700
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-planner
>            Reporter: Wouter Horr?
>            Assignee: Geoffrey De Smet
>
> Currently, it is not possible to set a global variable in the working memory used by the solver. If a scoring rule needs an external helper for calculating scores (e.g. a dependency injected with OSGi DS), a workaround using a static variable in some class accessible by the scoring rules is needed.
> The easiest implementation is probably a new method in the Solver interface:
> public WorkingMemory getWorkingMemory();
> which provides access to the working memory used by the solver.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Fri Jul 29 08:11:24 2011
From: jira-events at lists.jboss.org (Stefano Maestri (JIRA))
Date: Fri, 29 Jul 2011 08:11:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1164) add jdbc-driver :
 documentation incomplete or misleading
In-Reply-To: <2061849607.31723.1309511903626.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1832871192.91365.1311941484164.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefano Maestri reassigned AS7-1164:
------------------------------------

    Assignee: Jeff Zhang  (was: Stefano Maestri)


> add jdbc-driver : documentation incomplete or misleading
> --------------------------------------------------------
>
>                 Key: AS7-1164
>                 URL: https://issues.jboss.org/browse/AS7-1164
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management, JCA
>    Affects Versions: 7.0.0.CR1
>            Reporter: Heiko Rupp
>            Assignee: Jeff Zhang
>
> I want to add a jdbc driver to a profile. The driver has been uploaded to /deployment
> [domain at localhost:9999 subsystem=datasources] pwd
> /profile=default/subsystem=datasources
> [domain at localhost:9999 subsystem=datasources] ./jdbc-driver=postgres9:add(driver-name=postgres9,deployment-name=postgresql-9.0-801.jdbc4.jar,driver-class-name=org.postgresql.Driver)
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "Operation handler failed: java.util.NoSuchElementException: No child 'driver-module-name' exists"},
>     "rolled-back" => true
> }
> Documentation says:
> [domain at localhost:9999 jdbc-driver=h2] :read-operation-description(name=add)                 
> {
>     "outcome" => "success",
>     "result" => {
>         "operation-name" => "add",
>         "description" => "Adds a new JDBC driver service",
>         "attributes" => {
>             "driver-name" => {
>                 "description" => "The symbolic name of this driver used to reference it in the register",
>                 "type" => STRING,
>                 "required" => true
>             },
>             "deployment-name" => {
>                 "description" => "The name of the deployment unit from which the driver was loaded, if it was loaded from a deployment",
>                 "type" => STRING
>             },
>             "driver-module-name" => {
>                 "description" => "The name of the module from which the driver was loaded, if it was loaded from the module path",
>                 "type" => STRING
>             },
>             "module-slot" => {
>                 "description" => "The slot of the module from which the driver was loaded, if it was loaded from the module path",
>                 "type" => STRING
>             },
>             "driver-class-name" => {
>                 "description" => "The fully qualified class name of the driver's implementation of java.sql.Driver",
>                 "type" => STRING
>             },
>             "driver-major-version" => {
>                 "description" => "The driver's major version number",
>                 "type" => INT
>             },
>             "driver-minor-version" => {
>                 "description" => "The driver's minor version number",
>                 "type" => INT
>             },
>             "jdbc-compliant" => {
>                 "description" => "Whether or not the driver is JDBC compliant",
>                 "type" => BOOLEAN
>             }
>         }
>     }
> }
> Here, only the driver-name is required.
> For driver-module-name it says "if loaded from module", which I read as "optional".
> Obviously from above error message, this is not optional

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 08:13:23 2011
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 29 Jul 2011 08:13:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3160) Using a custom
 Score is not possible because it's not posssible to hook in the custom
 ScoreCalculator
Message-ID: <815043993.91369.1311941603602.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Using a custom Score is not possible because it's not posssible to hook in the custom ScoreCalculator
-----------------------------------------------------------------------------------------------------

                 Key: JBRULES-3160
                 URL: https://issues.jboss.org/browse/JBRULES-3160
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-planner
            Reporter: Geoffrey De Smet
            Assignee: Geoffrey De Smet
             Fix For: 5.3.0.Beta2


See http://stackoverflow.com/questions/6625000/drools-creating-a-custom-score/6872867#6872867

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 08:17:23 2011
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 29 Jul 2011 08:17:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-3160) Using a custom
 Score is not possible because it's not posssible to hook in the custom
 ScoreCalculator
In-Reply-To: <815043993.91369.1311941603602.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1756228689.91374.1311941843644.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617525#comment-12617525 ] 

Geoffrey De Smet commented on JBRULES-3160:
-------------------------------------------

For as long as we can't get rid of the ScoreCalculator, we should support it :(

> Using a custom Score is not possible because it's not posssible to hook in the custom ScoreCalculator
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3160
>                 URL: https://issues.jboss.org/browse/JBRULES-3160
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-planner
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>             Fix For: 5.3.0.Beta2
>
>
> See http://stackoverflow.com/questions/6625000/drools-creating-a-custom-score/6872867#6872867

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 08:32:24 2011
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 29 Jul 2011 08:32:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-9429)
 org.jboss.test.jbas8528.test.ApplicationNamingUnitTestCase.
Message-ID: <1400134153.91385.1311942744022.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

org.jboss.test.jbas8528.test.ApplicationNamingUnitTestCase.
-----------------------------------------------------------

                 Key: JBAS-9429
                 URL: https://issues.jboss.org/browse/JBAS-9429
             Project: Legacy JBoss Application Server 6 
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Shelly McGowan
             Fix For: 6.1.0


testApplicationDeployment:
vfs:///mnt/hudson_workspace/workspace/JBoss-AS-6.1.x-testSuite-sun16/JBossAS/testsuite/output/lib/jbas8528.ear

*** DEPLOYMENTS IN ERROR: Name -> Error

vfs:///mnt/hudson_workspace/workspace/JBoss-AS-6.1.x-testSuite-sun16/JBossAS/testsuite/output/lib/jbas8528.ear -> org.jboss.deployers.spi.DeploymentException: Unable to find class path entry ClassPathEntryImpl{path=jbas8528.war/WEB-INF} from jbas8528.ear




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 08:32:24 2011
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 29 Jul 2011 08:32:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-9430)
 org.jboss.test.web.test.ActiveRequestResponseCacheValveUnitTestCase
Message-ID: <708733596.91388.1311942744557.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

org.jboss.test.web.test.ActiveRequestResponseCacheValveUnitTestCase
-------------------------------------------------------------------

                 Key: JBAS-9430
                 URL: https://issues.jboss.org/browse/JBAS-9430
             Project: Legacy JBoss Application Server 6 
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Shelly McGowan
             Fix For: 6.1.0


testActiveRequestCaching:
java.io.IOException: Expected reply code:200, actual=404
	at org.jboss.test.util.web.HttpUtils.accessURL(HttpUtils.java:161)


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 08:32:25 2011
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 29 Jul 2011 08:32:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-9428)
 org.jboss.test.jca.test.DataSourceDeployerTestCase - JTS
In-Reply-To: <1048743586.90138.1311897743788.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2020654767.91390.1311942745017.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBAS-9428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan reassigned JBAS-9428:
------------------------------------

    Assignee: Shelly McGowan


> org.jboss.test.jca.test.DataSourceDeployerTestCase - JTS
> --------------------------------------------------------
>
>                 Key: JBAS-9428
>                 URL: https://issues.jboss.org/browse/JBAS-9428
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>
> testBasicDeployment:
> javax.management.InstanceNotFoundException: jboss.jca:name=DSEARXML,service=ManagedConnectionFactory is not registered.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 08:32:25 2011
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 29 Jul 2011 08:32:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-9429)
 org.jboss.test.jbas8528.test.ApplicationNamingUnitTestCase.
In-Reply-To: <1400134153.91385.1311942744022.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <456040701.91394.1311942745226.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBAS-9429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan reassigned JBAS-9429:
------------------------------------

    Assignee: Shelly McGowan


> org.jboss.test.jbas8528.test.ApplicationNamingUnitTestCase.
> -----------------------------------------------------------
>
>                 Key: JBAS-9429
>                 URL: https://issues.jboss.org/browse/JBAS-9429
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: 6.1.0
>
>
> testApplicationDeployment:
> vfs:///mnt/hudson_workspace/workspace/JBoss-AS-6.1.x-testSuite-sun16/JBossAS/testsuite/output/lib/jbas8528.ear
> *** DEPLOYMENTS IN ERROR: Name -> Error
> vfs:///mnt/hudson_workspace/workspace/JBoss-AS-6.1.x-testSuite-sun16/JBossAS/testsuite/output/lib/jbas8528.ear -> org.jboss.deployers.spi.DeploymentException: Unable to find class path entry ClassPathEntryImpl{path=jbas8528.war/WEB-INF} from jbas8528.ear

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 08:34:23 2011
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 29 Jul 2011 08:34:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-9426) org.jboss.jmx.test
	regressions
In-Reply-To: <531214594.90125.1311897263620.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2105605641.91396.1311942863895.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBAS-9426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan reassigned JBAS-9426:
------------------------------------

    Assignee: Shelly McGowan


> org.jboss.jmx.test regressions
> ------------------------------
>
>                 Key: JBAS-9426
>                 URL: https://issues.jboss.org/browse/JBAS-9426
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: 6.1.0
>
>
> Tests affected:
> org.jboss.test.jmx.test.JMXConnectorUnitTestCase
> org.jboss.test.jmx.test.JMXInvokerUnitTestCase
> org.jboss.test.jmx.test.SecureJMXInvokerUnitTestCase

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 09:21:24 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 29 Jul 2011 09:21:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1359) Upgrade to Hibernate
	4.0.0.Beta4
In-Reply-To: <1656580416.72347.1311251843659.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <959292224.91521.1311945684525.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow resolved AS7-1359.
-------------------------------

    Resolution: Done


> Upgrade to Hibernate 4.0.0.Beta4
> --------------------------------
>
>                 Key: AS7-1359
>                 URL: https://issues.jboss.org/browse/AS7-1359
>             Project: Application Server 7
>          Issue Type: Component  Upgrade
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 7.0.1.Final
>
>
> http://in.relation.to/Bloggers/HibernateCore400Beta4Release
> We are currently using Hibernate 4.0.0.Beta1, lets sync up with the latest Hibernate build

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 09:21:24 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 29 Jul 2011 09:21:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-1359) Upgrade to Hibernate
	4.0.0.Beta4
In-Reply-To: <1656580416.72347.1311251843659.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1279895496.91527.1311945684694.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow closed AS7-1359.
-----------------------------



> Upgrade to Hibernate 4.0.0.Beta4
> --------------------------------
>
>                 Key: AS7-1359
>                 URL: https://issues.jboss.org/browse/AS7-1359
>             Project: Application Server 7
>          Issue Type: Component  Upgrade
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 7.0.1.Final
>
>
> http://in.relation.to/Bloggers/HibernateCore400Beta4Release
> We are currently using Hibernate 4.0.0.Beta1, lets sync up with the latest Hibernate build

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 09:33:23 2011
From: jira-events at lists.jboss.org (Joshua Davis (JIRA))
Date: Fri, 29 Jul 2011 09:33:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1264) Add schema
 references to standalone.xml, domain.xml, host.xml
In-Reply-To: <1620974387.48924.1310488763828.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1554011961.91618.1311946403850.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617544#comment-12617544 ] 

Joshua Davis commented on AS7-1264:
-----------------------------------

RE: "switch that turns off validation" - I suppose you might want to disable validation on the production servers to prevent the server from failing to start if it can't find the XSDs over the internet.


> Add schema references to standalone.xml, domain.xml, host.xml
> -------------------------------------------------------------
>
>                 Key: AS7-1264
>                 URL: https://issues.jboss.org/browse/AS7-1264
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>    Affects Versions: 7.0.0.CR1
>            Reporter: Gerry Matte
>            Assignee: Brian Stansberry
>              Labels: domain, host, standalone, xml, xmlns
>
> It appears that users of Jboss 7 will be often modifying these configuration files as they fine tune their server and when they discover how to implement new features.
> It seems quite surprising to me that these files do not have the schema references identified in the file header.  Any good XML editor would use those references to validate changes and new entries and thereby avoid a great deal of frustration for users and those who provide support for forum issues.
> I realise that if jboss validated each xml file when starting up there would be performance penalty that may be unacceptable to many users.  A command-line switch could be used to either turn on xml validation (if the default were that no validation is performed) or conversely to turn off xml validation if the default state was that xml validation was on.
> Personally I favor having a switch that turns off validation - to be used on production servers only.
> If the schema/dtd files were published online and referenced within the configuration xml files, future changes to the schema structure would be "enforced" upon the user community as they attempted to use an out-of-date version when upgrading to a new version of JBoss AS 7. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 09:33:24 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 29 Jul 2011 09:33:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-566) Support for
 pluggable JPA providers
In-Reply-To: <282632663.33198.1300384486238.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1846800820.91633.1311946404265.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617545#comment-12617545 ] 

Scott Marlow commented on AS7-566:
----------------------------------

Documentation explaining how to package Hibernate3 jars for JPA use, will be added to above mentioned doc link.

http://community.jboss.org/thread/167590 describes how you can download a build with these changes.  

Although, I would rather see you download the AS7 source and build it yourself.  Test, fix problems that you run into (the AS7 code is easy/fun to play with).  More about this process is described in http://community.jboss.org/wiki/HackingOnAS7

If you want to try the code changes for this jira, before the doc is written, just add hibernate3 jars to your deployment and set the following property in your persistence unit (persistence.xml file):
<property name="jboss.as.jpa.providerModule" value="hibernate3-bundled"/>


> Support for pluggable JPA providers
> -----------------------------------
>
>                 Key: AS7-566
>                 URL: https://issues.jboss.org/browse/AS7-566
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: JPA / Hibernate
>            Reporter: David Lloyd
>            Assignee: Scott Marlow
>             Fix For: 7.1.0.Alpha1
>
>
> Maybe we could have a service per persistence provider that is based on a configuration settings.
> Questions:
> 1.  Where do the persistent provider jars go in the system?  Should we deploy them somehow?
> 2.  Each persistence.xml specifies the javax.persistence.spi.PersistenceProvider class name (via provider element) that it will use (defaults to whatever the AS7 default persistence provider).  The persistence.xml also allows vendor properties to be specified.  We could have an optional property "org.jboss.jpa.provider.versionSpecifier" that matches a specific version of the provider.
> Is this the best way to allow different versions of persistence provider?
> 3.  How could we best dynamically build a ModuleDependency on a persistence provider jar that 
> could be injected into a deployment (perhaps from JPADependencyProcessor)?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 09:33:24 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 29 Jul 2011 09:33:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-566) Support for pluggable
 JPA providers
In-Reply-To: <282632663.33198.1300384486238.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1422215935.91636.1311946404335.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow resolved AS7-566.
------------------------------

    Resolution: Done


> Support for pluggable JPA providers
> -----------------------------------
>
>                 Key: AS7-566
>                 URL: https://issues.jboss.org/browse/AS7-566
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: JPA / Hibernate
>            Reporter: David Lloyd
>            Assignee: Scott Marlow
>             Fix For: 7.1.0.Alpha1
>
>
> Maybe we could have a service per persistence provider that is based on a configuration settings.
> Questions:
> 1.  Where do the persistent provider jars go in the system?  Should we deploy them somehow?
> 2.  Each persistence.xml specifies the javax.persistence.spi.PersistenceProvider class name (via provider element) that it will use (defaults to whatever the AS7 default persistence provider).  The persistence.xml also allows vendor properties to be specified.  We could have an optional property "org.jboss.jpa.provider.versionSpecifier" that matches a specific version of the provider.
> Is this the best way to allow different versions of persistence provider?
> 3.  How could we best dynamically build a ModuleDependency on a persistence provider jar that 
> could be injected into a deployment (perhaps from JPADependencyProcessor)?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 09:35:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 29 Jul 2011 09:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-647) pluggable JPA
	providers
Message-ID: <1325416403.91648.1311946523889.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow resolved AS7-647.
------------------------------

    Resolution: Done


fixed against AS7-566

> pluggable JPA providers
> -----------------------
>
>                 Key: AS7-647
>                 URL: https://issues.jboss.org/browse/AS7-647
>             Project: Application Server 7
>          Issue Type: Task
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta3
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 7.1.0.Alpha1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 09:35:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 29 Jul 2011 09:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-647) pluggable JPA providers
Message-ID: <1525083119.91651.1311946523949.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow closed AS7-647.
----------------------------



> pluggable JPA providers
> -----------------------
>
>                 Key: AS7-647
>                 URL: https://issues.jboss.org/browse/AS7-647
>             Project: Application Server 7
>          Issue Type: Task
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta3
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 7.1.0.Alpha1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 09:35:24 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 29 Jul 2011 09:35:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-560) restructure use of
 JPA persistence provider specific details
In-Reply-To: <86206164.29198.1300282365988.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <884943058.91658.1311946524298.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow resolved AS7-560.
------------------------------

    Resolution: Done


fixed against AS7-566

> restructure use of JPA persistence provider specific details
> ------------------------------------------------------------
>
>                 Key: AS7-560
>                 URL: https://issues.jboss.org/browse/AS7-560
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta1
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 7.1.0.Alpha1
>
>
> Each one of these can become separate subtasks
> - Hibernate specific "static" properties should be in a system configuration file.
> - Hibernate specific code should be isolated at least.  At best, this code should be external to the AS, as separate project modules that implement a SPI.
> - Be able to obtain a PersistenceProvider specific classloader + temp classloader
> - Interweaved with the above, should be an improved PersistenceProviderResolver

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 09:35:24 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 29 Jul 2011 09:35:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-560) restructure use of JPA
 persistence provider specific details
In-Reply-To: <86206164.29198.1300282365988.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1407955665.91661.1311946524377.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow closed AS7-560.
----------------------------



> restructure use of JPA persistence provider specific details
> ------------------------------------------------------------
>
>                 Key: AS7-560
>                 URL: https://issues.jboss.org/browse/AS7-560
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta1
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 7.1.0.Alpha1
>
>
> Each one of these can become separate subtasks
> - Hibernate specific "static" properties should be in a system configuration file.
> - Hibernate specific code should be isolated at least.  At best, this code should be external to the AS, as separate project modules that implement a SPI.
> - Be able to obtain a PersistenceProvider specific classloader + temp classloader
> - Interweaved with the above, should be an improved PersistenceProviderResolver

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 09:35:24 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 29 Jul 2011 09:35:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-574) Deploy compatible
 versions of the Hibernate persistence provider with application deployments
In-Reply-To: <1407645652.12804.1302217473139.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <327335739.91667.1311946524614.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated AS7-574:
-----------------------------

    Fix Version/s: 7.0.1.Final
                       (was: 7.1.0.Alpha1)


> Deploy compatible versions of the Hibernate persistence provider with application deployments
> ---------------------------------------------------------------------------------------------
>
>                 Key: AS7-574
>                 URL: https://issues.jboss.org/browse/AS7-574
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 7.0.1.Final
>
>
> Deploy compatible versions of the Hibernate persistence provider with application deployments (e.g. EAR/lib could contain all of the Hibernate).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 09:35:24 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 29 Jul 2011 09:35:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-574) Deploy compatible
 versions of the Hibernate persistence provider with application deployments
In-Reply-To: <1407645652.12804.1302217473139.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1014440254.91669.1311946524694.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow resolved AS7-574.
------------------------------

    Resolution: Done


fixed against AS7-566

> Deploy compatible versions of the Hibernate persistence provider with application deployments
> ---------------------------------------------------------------------------------------------
>
>                 Key: AS7-574
>                 URL: https://issues.jboss.org/browse/AS7-574
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 7.0.1.Final
>
>
> Deploy compatible versions of the Hibernate persistence provider with application deployments (e.g. EAR/lib could contain all of the Hibernate).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 09:37:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 29 Jul 2011 09:37:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-574) Deploy compatible
 versions of the Hibernate persistence provider with application deployments
In-Reply-To: <1407645652.12804.1302217473139.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1122867651.91678.1311946643918.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow closed AS7-574.
----------------------------



> Deploy compatible versions of the Hibernate persistence provider with application deployments
> ---------------------------------------------------------------------------------------------
>
>                 Key: AS7-574
>                 URL: https://issues.jboss.org/browse/AS7-574
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 7.0.1.Final
>
>
> Deploy compatible versions of the Hibernate persistence provider with application deployments (e.g. EAR/lib could contain all of the Hibernate).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 09:37:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 29 Jul 2011 09:37:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (AS7-647) pluggable JPA
	providers
Message-ID: <1845573649.91681.1311946643985.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow reopened AS7-647:
------------------------------



> pluggable JPA providers
> -----------------------
>
>                 Key: AS7-647
>                 URL: https://issues.jboss.org/browse/AS7-647
>             Project: Application Server 7
>          Issue Type: Task
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta3
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 7.1.0.Alpha1
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 09:37:24 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 29 Jul 2011 09:37:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-647) pluggable JPA providers
Message-ID: <309006182.91707.1311946644832.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated AS7-647:
-----------------------------

    Fix Version/s: 7.0.1.Final
                       (was: 7.1.0.Alpha1)


> pluggable JPA providers
> -----------------------
>
>                 Key: AS7-647
>                 URL: https://issues.jboss.org/browse/AS7-647
>             Project: Application Server 7
>          Issue Type: Task
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta3
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 7.0.1.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 09:37:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 29 Jul 2011 09:37:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-2227) @Startup
 @Singleton (via switchboard) should take into account transitive ENC
 dependencies before instantiating the bean
In-Reply-To: <65976238.34871.1294150758446.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <308404094.91705.1311946644762.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/EJBTHREE-2227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-2227.
------------------------------------

    Component Fix Version(s): jboss-ejb3-singleton:1.0.2
               Fix Version/s: depchain-1.0.3
                  Resolution: Done


Fixed in 1.0.2 of jboss-ejb3-singleton

> @Startup @Singleton (via switchboard) should take into account transitive ENC dependencies before instantiating the bean
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-2227
>                 URL: https://issues.jboss.org/browse/EJBTHREE-2227
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: singleton
>    Affects Versions: depchain-1.0.0-alpha-43
>         Environment: JBoss AS 6.0 Final
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>            Priority: Critical
>             Fix For: depchain-1.0.3
>
>
> Consider the following beans:
> @Startup 
> @Singleton
> public class A
> {
>  @EJB
>  private B slsb1;
>  @PostConstruct
>  public void onConstruct()
>  {
>    slsb1.doSomething();
>  } 
> }
> @Stateless
> public class B
> {
>   @EJB
>   private C slsb2;
> }
> @Stateless
> public class C
> {
> ....
> }
> Currently, the @Startup @Singleton is instantiated when the ENC of that bean is fully invokable. However, it only waits for a populated ENC of transitive dependent bean(s). This can lead random failures with lookup. Please see the referenced forum thread for the complete details.
>  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 09:37:25 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 29 Jul 2011 09:37:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-647) pluggable JPA
	providers
Message-ID: <1897015572.91715.1311946645055.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow resolved AS7-647.
------------------------------

    Resolution: Done


> pluggable JPA providers
> -----------------------
>
>                 Key: AS7-647
>                 URL: https://issues.jboss.org/browse/AS7-647
>             Project: Application Server 7
>          Issue Type: Task
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta3
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 7.0.1.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 09:37:25 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 29 Jul 2011 09:37:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-647) pluggable JPA providers
Message-ID: <539709434.91720.1311946645189.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow closed AS7-647.
----------------------------



> pluggable JPA providers
> -----------------------
>
>                 Key: AS7-647
>                 URL: https://issues.jboss.org/browse/AS7-647
>             Project: Application Server 7
>          Issue Type: Task
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta3
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 7.0.1.Final
>
>


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 09:37:25 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 29 Jul 2011 09:37:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (AS7-560) restructure use of
 JPA persistence provider specific details
In-Reply-To: <86206164.29198.1300282365988.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1552297785.91722.1311946645235.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow reopened AS7-560:
------------------------------



> restructure use of JPA persistence provider specific details
> ------------------------------------------------------------
>
>                 Key: AS7-560
>                 URL: https://issues.jboss.org/browse/AS7-560
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta1
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 7.1.0.Alpha1
>
>
> Each one of these can become separate subtasks
> - Hibernate specific "static" properties should be in a system configuration file.
> - Hibernate specific code should be isolated at least.  At best, this code should be external to the AS, as separate project modules that implement a SPI.
> - Be able to obtain a PersistenceProvider specific classloader + temp classloader
> - Interweaved with the above, should be an improved PersistenceProviderResolver

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 09:39:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 29 Jul 2011 09:39:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-560) restructure use of JPA
 persistence provider specific details
In-Reply-To: <86206164.29198.1300282365988.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <344584198.91726.1311946763772.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated AS7-560:
-----------------------------

    Fix Version/s: 7.0.1.Final
                       (was: 7.1.0.Alpha1)
      Description: 
Each one of these can become separate subtasks

- Hibernate specific "static" properties should be in a system configuration file.

- Hibernate specific code should be isolated at least.  At best, this code should be external to the AS, as separate project modules that implement a SPI.




  was:
Each one of these can become separate subtasks

- Hibernate specific "static" properties should be in a system configuration file.

- Hibernate specific code should be isolated at least.  At best, this code should be external to the AS, as separate project modules that implement a SPI.

- Be able to obtain a PersistenceProvider specific classloader + temp classloader

- Interweaved with the above, should be an improved PersistenceProviderResolver





> restructure use of JPA persistence provider specific details
> ------------------------------------------------------------
>
>                 Key: AS7-560
>                 URL: https://issues.jboss.org/browse/AS7-560
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta1
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 7.0.1.Final
>
>
> Each one of these can become separate subtasks
> - Hibernate specific "static" properties should be in a system configuration file.
> - Hibernate specific code should be isolated at least.  At best, this code should be external to the AS, as separate project modules that implement a SPI.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 09:39:24 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 29 Jul 2011 09:39:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-560) restructure use of
 JPA persistence provider specific details
In-Reply-To: <86206164.29198.1300282365988.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <718262738.91729.1311946764049.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow resolved AS7-560.
------------------------------

    Resolution: Done


> restructure use of JPA persistence provider specific details
> ------------------------------------------------------------
>
>                 Key: AS7-560
>                 URL: https://issues.jboss.org/browse/AS7-560
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta1
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 7.0.1.Final
>
>
> Each one of these can become separate subtasks
> - Hibernate specific "static" properties should be in a system configuration file.
> - Hibernate specific code should be isolated at least.  At best, this code should be external to the AS, as separate project modules that implement a SPI.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 09:39:24 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 29 Jul 2011 09:39:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-566) Support for pluggable
	JPA providers
In-Reply-To: <282632663.33198.1300384486238.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <481747882.91735.1311946764206.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated AS7-566:
-----------------------------

    Fix Version/s: 7.0.1.Final
                       (was: 7.1.0.Alpha1)
      Description: 
Maybe we could have a service per persistence provider that is based on a configuration settings.

Questions:

1.  Where do the persistent provider jars go in the system?  Should we deploy them somehow?

2.  Each persistence.xml specifies the javax.persistence.spi.PersistenceProvider class name (via provider element) that it will use (defaults to whatever the AS7 default persistence provider).  The persistence.xml also allows vendor properties to be specified.  

3.  How could we best dynamically build a ModuleDependency on a persistence provider jar that 
could be injected into a deployment (perhaps from JPADependencyProcessor)?



  was:
Maybe we could have a service per persistence provider that is based on a configuration settings.

Questions:

1.  Where do the persistent provider jars go in the system?  Should we deploy them somehow?

2.  Each persistence.xml specifies the javax.persistence.spi.PersistenceProvider class name (via provider element) that it will use (defaults to whatever the AS7 default persistence provider).  The persistence.xml also allows vendor properties to be specified.  We could have an optional property "org.jboss.jpa.provider.versionSpecifier" that matches a specific version of the provider.

Is this the best way to allow different versions of persistence provider?

3.  How could we best dynamically build a ModuleDependency on a persistence provider jar that 
could be injected into a deployment (perhaps from JPADependencyProcessor)?





> Support for pluggable JPA providers
> -----------------------------------
>
>                 Key: AS7-566
>                 URL: https://issues.jboss.org/browse/AS7-566
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: JPA / Hibernate
>            Reporter: David Lloyd
>            Assignee: Scott Marlow
>             Fix For: 7.0.1.Final
>
>
> Maybe we could have a service per persistence provider that is based on a configuration settings.
> Questions:
> 1.  Where do the persistent provider jars go in the system?  Should we deploy them somehow?
> 2.  Each persistence.xml specifies the javax.persistence.spi.PersistenceProvider class name (via provider element) that it will use (defaults to whatever the AS7 default persistence provider).  The persistence.xml also allows vendor properties to be specified.  
> 3.  How could we best dynamically build a ModuleDependency on a persistence provider jar that 
> could be injected into a deployment (perhaps from JPADependencyProcessor)?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 09:39:24 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 29 Jul 2011 09:39:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-560) restructure use of JPA
 persistence provider specific details
In-Reply-To: <86206164.29198.1300282365988.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1715496010.91732.1311946764123.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow closed AS7-560.
----------------------------



> restructure use of JPA persistence provider specific details
> ------------------------------------------------------------
>
>                 Key: AS7-560
>                 URL: https://issues.jboss.org/browse/AS7-560
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Beta1
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 7.0.1.Final
>
>
> Each one of these can become separate subtasks
> - Hibernate specific "static" properties should be in a system configuration file.
> - Hibernate specific code should be isolated at least.  At best, this code should be external to the AS, as separate project modules that implement a SPI.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 09:41:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Fri, 29 Jul 2011 09:41:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (AS7-566) Support for pluggable
	JPA providers
In-Reply-To: <282632663.33198.1300384486238.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <301597281.91747.1311946883835.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow closed AS7-566.
----------------------------



> Support for pluggable JPA providers
> -----------------------------------
>
>                 Key: AS7-566
>                 URL: https://issues.jboss.org/browse/AS7-566
>             Project: Application Server 7
>          Issue Type: Sub-task
>          Components: JPA / Hibernate
>            Reporter: David Lloyd
>            Assignee: Scott Marlow
>             Fix For: 7.0.1.Final
>
>
> Maybe we could have a service per persistence provider that is based on a configuration settings.
> Questions:
> 1.  Where do the persistent provider jars go in the system?  Should we deploy them somehow?
> 2.  Each persistence.xml specifies the javax.persistence.spi.PersistenceProvider class name (via provider element) that it will use (defaults to whatever the AS7 default persistence provider).  The persistence.xml also allows vendor properties to be specified.  
> 3.  How could we best dynamically build a ModuleDependency on a persistence provider jar that 
> could be injected into a deployment (perhaps from JPADependencyProcessor)?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 09:41:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 29 Jul 2011 09:41:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-9424) MDB's are started
 *BEFORE* EJB's are jndi-bound
In-Reply-To: <360076107.88062.1311852623683.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1647651967.91763.1311946884496.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBAS-9424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617551#comment-12617551 ] 

jaikiran pai commented on JBAS-9424:
------------------------------------

Please try against latest AS6 nightly build http://community.jboss.org/thread/161386. Also if that doesn't work, then please try using @EJB instead of @Inject.


> MDB's are started *BEFORE* EJB's are jndi-bound
> -----------------------------------------------
>
>                 Key: JBAS-9424
>                 URL: https://issues.jboss.org/browse/JBAS-9424
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB, Weld/CDI
>    Affects Versions: 6.0.0.Final
>         Environment: All (*NIX, Mac-Os-X and Win)
>            Reporter: Bernard Ligny
>            Assignee: Carlo de Wolf
>            Priority: Critical
>
> I recently noticed a very strange behaviour (with JBOSS AS 6) with Message-Driven-Beans where we inject EJB.
> If the JMS queue is empty when the jboss server is started, then everything works fine.
> If, no luck, the jms queue is *NOT* empty, my MDB is apparently mounted *BEFORE* the ejb's
> and the @Inject failed:
> => "Failure WELD-000079 Could not find the EJB in JNDI:  class xxx"
> I further investigated the problem:
> I replaced the @Inject annotation, with a "manual" lookup of my ejb 
> using the javax.enterprise.inject.spi.BeanManager capabilities (that i put in a @Postcontruct method of my MDB), 
> The trick consisted in trying the lookup n times with a delay of x sec between each attempt.
> Here are the results (excerpt from server.log):
> {code:xml} 
> 2011-07-28 12:05:06,180 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [1] Trying to lookup KernelResources
> 2011-07-28 12:05:06,190 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [1] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:11,191 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [2] Trying to lookup KernelResources
> 2011-07-28 12:05:11,192 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [2] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:16,193 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [3] Trying to lookup KernelResources
> 2011-07-28 12:05:16,193 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [3] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:21,194 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [4] Trying to lookup KernelResources
> 2011-07-28 12:05:21,194 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [4] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:26,195 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [5] Trying to lookup KernelResources
> 2011-07-28 12:05:26,195 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [5] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:26,215 INFO  [org.jboss.ejb3.nointerface.impl.jndi.AbstractNoInterfaceViewBinder] (Thread-3) Binding the following entry in Global JNDI for bean:KernelResources
> => finally the EJB is bound !
> 2011-07-28 12:05:31,196 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [6] Trying to lookup KernelResources
> 2011-07-28 12:05:31,197 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** KernelResources = No-Interface view for endpoint [ jboss.j2ee:ear=energycomm-ear.ear,jar=energycomm-kernel-0.5.0-SNAPSHOT.jar,name=KernelResources,service=EJB3 ]
> => the 6th attempt now works :-)
> {code} 
> Conclusion: according to me, there is no doubt: dependencies between MDB's and EJB's are not correctly managed by the app server.
> The app server should wait for all EJB's to be bound before activating the MDB.
> MDB are activated too early (especially when jms queue is not empty at starttime)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 09:53:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 29 Jul 2011 09:53:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-8901) dependency
 injection fails when deploying large graphs of inter-dependent EJBs
In-Reply-To: <466018060.19950.1298044573743.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <79076728.91805.1311947603834.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBAS-8901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved JBAS-8901.
--------------------------------

    Resolution: Done


Fixed in r111882. Please try the latest AS6 nightly build http://community.jboss.org/thread/161386

> dependency injection fails when deploying large graphs of inter-dependent EJBs
> ------------------------------------------------------------------------------
>
>                 Key: JBAS-8901
>                 URL: https://issues.jboss.org/browse/JBAS-8901
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB
>    Affects Versions: 6.0.0.Final
>         Environment: windows xp 32bit, jdk 6u23
>            Reporter: Radai Rosenblatt
>            Assignee: jaikiran pai
>             Fix For: 6.1.0
>
>         Attachments: ear-1.0-SNAPSHOT.ear, ear-generator.zip
>
>
> i've attached a maven project that generates a random ear containing 100 EJBs that are inter-denendent. the graph generated is directed (no loops). graph roots are @Singleton @Startup beans that have a @PostConstruct method. in this method, they access all of their injected @EJBs, which then do the same recursively. the ears generated deploy fine for small cases (5 beans), but when trying to deploy a 100-bean ear several injections fail.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 09:59:23 2011
From: jira-events at lists.jboss.org (Bernard Ligny (JIRA))
Date: Fri, 29 Jul 2011 09:59:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-9424) MDB's are started
 *BEFORE* EJB's are jndi-bound
In-Reply-To: <360076107.88062.1311852623683.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1308206605.91829.1311947963684.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBAS-9424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617558#comment-12617558 ] 

Bernard Ligny commented on JBAS-9424:
-------------------------------------

Thx for your quick response.
I already tried (but with "6.0.0.Final") with @EJB isof @Inject: the error message is slightly different but the problem still remains.
Anyway, i gonna give a try to the latest nightly build....

> MDB's are started *BEFORE* EJB's are jndi-bound
> -----------------------------------------------
>
>                 Key: JBAS-9424
>                 URL: https://issues.jboss.org/browse/JBAS-9424
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB, Weld/CDI
>    Affects Versions: 6.0.0.Final
>         Environment: All (*NIX, Mac-Os-X and Win)
>            Reporter: Bernard Ligny
>            Assignee: Carlo de Wolf
>            Priority: Critical
>
> I recently noticed a very strange behaviour (with JBOSS AS 6) with Message-Driven-Beans where we inject EJB.
> If the JMS queue is empty when the jboss server is started, then everything works fine.
> If, no luck, the jms queue is *NOT* empty, my MDB is apparently mounted *BEFORE* the ejb's
> and the @Inject failed:
> => "Failure WELD-000079 Could not find the EJB in JNDI:  class xxx"
> I further investigated the problem:
> I replaced the @Inject annotation, with a "manual" lookup of my ejb 
> using the javax.enterprise.inject.spi.BeanManager capabilities (that i put in a @Postcontruct method of my MDB), 
> The trick consisted in trying the lookup n times with a delay of x sec between each attempt.
> Here are the results (excerpt from server.log):
> {code:xml} 
> 2011-07-28 12:05:06,180 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [1] Trying to lookup KernelResources
> 2011-07-28 12:05:06,190 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [1] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:11,191 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [2] Trying to lookup KernelResources
> 2011-07-28 12:05:11,192 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [2] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:16,193 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [3] Trying to lookup KernelResources
> 2011-07-28 12:05:16,193 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [3] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:21,194 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [4] Trying to lookup KernelResources
> 2011-07-28 12:05:21,194 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [4] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:26,195 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [5] Trying to lookup KernelResources
> 2011-07-28 12:05:26,195 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [5] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:26,215 INFO  [org.jboss.ejb3.nointerface.impl.jndi.AbstractNoInterfaceViewBinder] (Thread-3) Binding the following entry in Global JNDI for bean:KernelResources
> => finally the EJB is bound !
> 2011-07-28 12:05:31,196 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [6] Trying to lookup KernelResources
> 2011-07-28 12:05:31,197 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** KernelResources = No-Interface view for endpoint [ jboss.j2ee:ear=energycomm-ear.ear,jar=energycomm-kernel-0.5.0-SNAPSHOT.jar,name=KernelResources,service=EJB3 ]
> => the 6th attempt now works :-)
> {code} 
> Conclusion: according to me, there is no doubt: dependencies between MDB's and EJB's are not correctly managed by the app server.
> The app server should wait for all EJB's to be bound before activating the MDB.
> MDB are activated too early (especially when jms queue is not empty at starttime)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 10:01:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 29 Jul 2011 10:01:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-2228) EJB Injection
 issue in @Service annotated MBean
In-Reply-To: <388680905.35748.1294159218287.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1666643411.91835.1311948083978.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/EJBTHREE-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai resolved EJBTHREE-2228.
------------------------------------

    Fix Version/s: depchain-1.0.3
       Resolution: Done


AS6 trunk r111882 should contain a fix for this. Please try latest AS6 nightly build http://community.jboss.org/thread/161386

> EJB Injection issue in @Service annotated MBean
> -----------------------------------------------
>
>                 Key: EJBTHREE-2228
>                 URL: https://issues.jboss.org/browse/EJBTHREE-2228
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: JBoss AS 6.0 Final 
>            Reporter: Gregoire Botquin
>            Assignee: jaikiran pai
>             Fix For: depchain-1.0.3
>
>
> I'm currently working on a migration of an application running on 4.2.2 to 6.0. The application still uses a lot of MBeans (still working with @Service @Management ... annotations). I know that  these annotations are more or less deprecated, but the deployment was working fine in CR1. Now I got same kind of problems as posts refering to bug https://issues.jboss.org/browse/EJBTHREE-2227. I got EJB injection problems. Even if I try to do the lookups mannually it only randomly works.
> As example you have :
> @Service
> @Management
> public MyMBEan{
> @EJB
> MyEjbClass c;
> }
> @Stateless
> public MyEjbClass{
> ...
> }
> Even if I add a dependency (@Depends) on the EJB, it works randomly....
> Kind of Stack traces obtained when it doesn't work : 
> Caused by: javax.naming.NamingException: Could not dereference object [Root exception is javax.naming.NameNotFoundException: MyConnectionFactory not bound]
>         at org.jnp.interfaces.NamingContext.resolveLink(NamingContext.java:1356) [:5.0.5.Final]
>         at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:819) [:5.0.5.Final]
>         at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:835) [:5.0.5.Final]
>         at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:688) [:5.0.5.Final]
>         at javax.naming.InitialContext.lookup(InitialContext.java:392) [:1.6.0_20]
>         at org.jboss.injection.injector.EEInjector.lookup(EEInjector.java:153) [:1.0.0-alpha-6]
>         at org.jboss.injection.injector.EEInjector.inject(EEInjector.java:133) [:1.0.0-alpha-6]
>         at org.jboss.injection.injector.EEInjector.inject(EEInjector.java:82) [:1.0.0-alpha-6]
>         ... 90 more
> Caused by: javax.naming.NameNotFoundException: MyConnectionFactory not bound
>         at org.jnp.server.NamingServer.getBinding(NamingServer.java:771) [:5.0.5.Final]
>         at org.jnp.server.NamingServer.getBinding(NamingServer.java:779) [:5.0.5.Final]
>         at org.jnp.server.NamingServer.getObject(NamingServer.java:785) [:5.0.5.Final]
>         at org.jnp.server.NamingServer.lookup(NamingServer.java:443) [:5.0.5.Final]
>         at org.jnp.server.NamingServer.lookup(NamingServer.java:399) [:5.0.5.Final]
>         at org.jnp.server.NamingServer.lookup(NamingServer.java:399) [:5.0.5.Final]
>         at org.jnp.server.NamingServer.lookup(NamingServer.java:399) [:5.0.5.Final]
>         at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:728) [:5.0.5.Final]
>         at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:688) [:5.0.5.Final]
>         at javax.naming.InitialContext.lookup(InitialContext.java:392) [:1.6.0_20]
>         at org.jnp.interfaces.NamingContext.resolveLink(NamingContext.java:1350) [:5.0.5.Final]
>         ... 97 more
> OR 
> 17:18:34,052 ERROR [ServiceContainer] Encountered an error in start of SubcriptionTimerMBean: org.jboss.injection.manager.spi.InjectionException: javax.naming.NameNotFoundException: preroutingMessageProducer not bound
>         at org.jboss.injection.injector.EEInjector.inject(EEInjector.java:87) [:1.0.0-alpha-6]
>         at org.jboss.injection.manager.core.DefaultInjectionContext.proceed(DefaultInjectionContext.java:58) [:1.0.0-alpha-6]
>         at org.jboss.injection.manager.core.DefaultInjectionManager.inject(DefaultInjectionManager.java:58) [:1.0.0-alpha-6]
>         at org.jboss.injection.manager.core.DefaultInjectionManager.inject(DefaultInjectionManager.java:64) [:1.0.0-alpha-6]
>         at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:140) [:1.7.17]
>         at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:125) [:1.7.17]
>         at org.jboss.ejb3.core.context.CurrentInvocationContextInterceptor.invoke(CurrentInvocationContextInterceptor.java:47) [:1.7.17]
>         at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:116) [:1.7.17]
>         at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67) [:1.0.1]
>         at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:116) [:1.7.17]
>         at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1363) [:1.7.17]
>         at org.jboss.ejb3.service.ServiceContainer.injectDependencies(ServiceContainer.java:555) [:1.7.17]
>         at org.jboss.ejb3.service.ServiceContainer.createBeanContext(ServiceContainer.java:151) [:1.7.17]
>         at org.jboss.ejb3.service.ServiceContainer.initBeanContext(ServiceContainer.java:530) [:1.7.17]
>         at org.jboss.ejb3.service.ServiceContainer.lockedStart(ServiceContainer.java:261) [:1.7.17]
>         at org.jboss.ejb3.EJBContainer.start(EJBContainer.java:1105) [:1.7.17]
>         at org.jboss.ejb3.service.ServiceContainer.start(ServiceContainer.java:796) [:1.7.17]
>         at sun.reflect.GeneratedMethodAccessor525.invoke(Unknown Source) [:1.6.0_20]
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20]
>         at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20]
>         at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:60) [jboss-reflect.jar:2.2.0.GA]
>         at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.0.GA]
>         at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) [jboss-reflect.jar:2.2.0.GA]
>         at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:257) [jboss-kernel.jar:2.2.0.GA]
>         at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47) [jboss-kernel.jar:2.2.0.GA]
>         at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:125) [jboss-kernel.jar:2.2.0.GA]
>         at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:72) [jboss-kernel.jar:2.2.0.GA]
>         at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:202) [jboss-kernel.jar:2.2.0.GA]
>         at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.GA]
>         at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:894) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:641) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:182) [:2.2.0.GA]
>         at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:58) [:2.2.0.GA]
>         at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) [:2.2.0.GA]
>         at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.0.GA]
>         at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.GA]
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.0.GA]
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.0.GA]
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1571) [:2.2.0.GA]
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1603) [:2.2.0.GA]
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.0.GA]
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.0.GA]
>         at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.0.GA]
>         at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.0.GA]
>         at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.0.0.Final]
>         at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:143) [:0.2.2]
>         at org.jboss.profileservice.dependency.ProfileDeployAction.deploy(ProfileDeployAction.java:151) [:0.2.2]
>         at org.jboss.profileservice.dependency.ProfileDeployAction.installActionInternal(ProfileDeployAction.java:94) [:0.2.2]
>         at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.GA]
>         at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.GA]
>         at org.jboss.profileservice.dependency.ProfileActivationWrapper$BasicProfileActivation.start(ProfileActivationWrapper.java:190) [:0.2.2]
>         at org.jboss.profileservice.dependency.ProfileActivationWrapper.start(ProfileActivationWrapper.java:87) [:0.2.2]
>         at org.jboss.profileservice.dependency.ProfileActivationService.activateProfile(ProfileActivationService.java:215) [:0.2.2]
>         at org.jboss.profileservice.dependency.ProfileActivationService.activate(ProfileActivationService.java:159) [:0.2.2]
>         at org.jboss.profileservice.bootstrap.AbstractProfileServiceBootstrap.activate(AbstractProfileServiceBootstrap.java:112) [:0.2.2]
>         at org.jboss.profileservice.resolver.BasicResolverFactory$ProfileResolverFacade.deploy(BasicResolverFactory.java:87) [:0.2.2]
>         at org.jboss.profileservice.bootstrap.AbstractProfileServiceBootstrap.start(AbstractProfileServiceBootstrap.java:91) [:0.2.2]
>         at org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceBootstrap.start(BasicProfileServiceBootstrap.java:132) [:6.0.0.Final]
>         at org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceBootstrap.start(BasicProfileServiceBootstrap.java:56) [:6.0.0.Final]
>         at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:827) [jboss-bootstrap-impl-base.jar:2.1.0-alpha-5]
>         at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:417) [jboss-bootstrap-impl-base.jar:2.1.0-alpha-5]
>         at java.lang.Thread.run(Thread.java:619) [:1.6.0_20]
> Caused by: javax.naming.NameNotFoundException: preroutingMessageProducer not bound
>         at org.jnp.server.NamingServer.getBinding(NamingServer.java:771) [:5.0.5.Final]
>         at org.jnp.server.NamingServer.getBinding(NamingServer.java:779) [:5.0.5.Final]
>         at org.jnp.server.NamingServer.getObject(NamingServer.java:785) [:5.0.5.Final]
>         at org.jnp.server.NamingServer.lookup(NamingServer.java:443) [:5.0.5.Final]
>         at org.jnp.server.NamingServer.lookup(NamingServer.java:399) [:5.0.5.Final]
>         at org.jnp.server.NamingServer.lookup(NamingServer.java:399) [:5.0.5.Final]
>         at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:728) [:5.0.5.Final]
>         at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:835) [:5.0.5.Final]
>         at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:688) [:5.0.5.Final]
>         at javax.naming.InitialContext.lookup(InitialContext.java:392) [:1.6.0_20]
>         at org.jboss.injection.injector.EEInjector.lookup(EEInjector.java:153) [:1.0.0-alpha-6]
>         at org.jboss.injection.injector.EEInjector.inject(EEInjector.java:133) [:1.0.0-alpha-6]
>         at org.jboss.injection.injector.EEInjector.inject(EEInjector.java:82) [:1.0.0-alpha-6]
>         ... 90 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 10:01:24 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 29 Jul 2011 10:01:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-9424) MDB's are started
 *BEFORE* EJB's are jndi-bound
In-Reply-To: <360076107.88062.1311852623683.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1528531567.91844.1311948084262.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBAS-9424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617560#comment-12617560 ] 

jaikiran pai commented on JBAS-9424:
------------------------------------

When you try the latest build make sure you have the r11182 commit. The build should be published shortly.


> MDB's are started *BEFORE* EJB's are jndi-bound
> -----------------------------------------------
>
>                 Key: JBAS-9424
>                 URL: https://issues.jboss.org/browse/JBAS-9424
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB, Weld/CDI
>    Affects Versions: 6.0.0.Final
>         Environment: All (*NIX, Mac-Os-X and Win)
>            Reporter: Bernard Ligny
>            Assignee: Carlo de Wolf
>            Priority: Critical
>
> I recently noticed a very strange behaviour (with JBOSS AS 6) with Message-Driven-Beans where we inject EJB.
> If the JMS queue is empty when the jboss server is started, then everything works fine.
> If, no luck, the jms queue is *NOT* empty, my MDB is apparently mounted *BEFORE* the ejb's
> and the @Inject failed:
> => "Failure WELD-000079 Could not find the EJB in JNDI:  class xxx"
> I further investigated the problem:
> I replaced the @Inject annotation, with a "manual" lookup of my ejb 
> using the javax.enterprise.inject.spi.BeanManager capabilities (that i put in a @Postcontruct method of my MDB), 
> The trick consisted in trying the lookup n times with a delay of x sec between each attempt.
> Here are the results (excerpt from server.log):
> {code:xml} 
> 2011-07-28 12:05:06,180 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [1] Trying to lookup KernelResources
> 2011-07-28 12:05:06,190 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [1] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:11,191 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [2] Trying to lookup KernelResources
> 2011-07-28 12:05:11,192 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [2] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:16,193 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [3] Trying to lookup KernelResources
> 2011-07-28 12:05:16,193 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [3] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:21,194 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [4] Trying to lookup KernelResources
> 2011-07-28 12:05:21,194 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [4] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:26,195 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [5] Trying to lookup KernelResources
> 2011-07-28 12:05:26,195 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [5] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:26,215 INFO  [org.jboss.ejb3.nointerface.impl.jndi.AbstractNoInterfaceViewBinder] (Thread-3) Binding the following entry in Global JNDI for bean:KernelResources
> => finally the EJB is bound !
> 2011-07-28 12:05:31,196 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [6] Trying to lookup KernelResources
> 2011-07-28 12:05:31,197 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** KernelResources = No-Interface view for endpoint [ jboss.j2ee:ear=energycomm-ear.ear,jar=energycomm-kernel-0.5.0-SNAPSHOT.jar,name=KernelResources,service=EJB3 ]
> => the 6th attempt now works :-)
> {code} 
> Conclusion: according to me, there is no doubt: dependencies between MDB's and EJB's are not correctly managed by the app server.
> The app server should wait for all EJB's to be bound before activating the MDB.
> MDB are activated too early (especially when jms queue is not empty at starttime)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 10:20:23 2011
From: jira-events at lists.jboss.org (Bernard Ligny (JIRA))
Date: Fri, 29 Jul 2011 10:20:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-9424) MDB's are started
 *BEFORE* EJB's are jndi-bound
In-Reply-To: <360076107.88062.1311852623683.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1402834316.91876.1311949223795.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBAS-9424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617561#comment-12617561 ] 

Bernard Ligny commented on JBAS-9424:
-------------------------------------

I'm a bit confused.
Where will i be able to find such "r11182" ?
The latest available AS build (eg https://hudson.jboss.org/jenkins/view/JBoss%20AS/job/JBoss-AS-6.1.x/lastBuild/) has a "Revision: 111869"
(BTW: 111869 > 11182) ??



> MDB's are started *BEFORE* EJB's are jndi-bound
> -----------------------------------------------
>
>                 Key: JBAS-9424
>                 URL: https://issues.jboss.org/browse/JBAS-9424
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB, Weld/CDI
>    Affects Versions: 6.0.0.Final
>         Environment: All (*NIX, Mac-Os-X and Win)
>            Reporter: Bernard Ligny
>            Assignee: Carlo de Wolf
>            Priority: Critical
>
> I recently noticed a very strange behaviour (with JBOSS AS 6) with Message-Driven-Beans where we inject EJB.
> If the JMS queue is empty when the jboss server is started, then everything works fine.
> If, no luck, the jms queue is *NOT* empty, my MDB is apparently mounted *BEFORE* the ejb's
> and the @Inject failed:
> => "Failure WELD-000079 Could not find the EJB in JNDI:  class xxx"
> I further investigated the problem:
> I replaced the @Inject annotation, with a "manual" lookup of my ejb 
> using the javax.enterprise.inject.spi.BeanManager capabilities (that i put in a @Postcontruct method of my MDB), 
> The trick consisted in trying the lookup n times with a delay of x sec between each attempt.
> Here are the results (excerpt from server.log):
> {code:xml} 
> 2011-07-28 12:05:06,180 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [1] Trying to lookup KernelResources
> 2011-07-28 12:05:06,190 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [1] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:11,191 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [2] Trying to lookup KernelResources
> 2011-07-28 12:05:11,192 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [2] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:16,193 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [3] Trying to lookup KernelResources
> 2011-07-28 12:05:16,193 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [3] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:21,194 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [4] Trying to lookup KernelResources
> 2011-07-28 12:05:21,194 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [4] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:26,195 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [5] Trying to lookup KernelResources
> 2011-07-28 12:05:26,195 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [5] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:26,215 INFO  [org.jboss.ejb3.nointerface.impl.jndi.AbstractNoInterfaceViewBinder] (Thread-3) Binding the following entry in Global JNDI for bean:KernelResources
> => finally the EJB is bound !
> 2011-07-28 12:05:31,196 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [6] Trying to lookup KernelResources
> 2011-07-28 12:05:31,197 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** KernelResources = No-Interface view for endpoint [ jboss.j2ee:ear=energycomm-ear.ear,jar=energycomm-kernel-0.5.0-SNAPSHOT.jar,name=KernelResources,service=EJB3 ]
> => the 6th attempt now works :-)
> {code} 
> Conclusion: according to me, there is no doubt: dependencies between MDB's and EJB's are not correctly managed by the app server.
> The app server should wait for all EJB's to be bound before activating the MDB.
> MDB are activated too early (especially when jms queue is not empty at starttime)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 10:22:23 2011
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 29 Jul 2011 10:22:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-9424) MDB's are started
 *BEFORE* EJB's are jndi-bound
In-Reply-To: <360076107.88062.1311852623683.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1746103424.91888.1311949343764.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBAS-9424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617562#comment-12617562 ] 

jaikiran pai commented on JBAS-9424:
------------------------------------

Sorry, I meant 111882. And yes, that's the right place to check the revision number. 

> MDB's are started *BEFORE* EJB's are jndi-bound
> -----------------------------------------------
>
>                 Key: JBAS-9424
>                 URL: https://issues.jboss.org/browse/JBAS-9424
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB, Weld/CDI
>    Affects Versions: 6.0.0.Final
>         Environment: All (*NIX, Mac-Os-X and Win)
>            Reporter: Bernard Ligny
>            Assignee: Carlo de Wolf
>            Priority: Critical
>
> I recently noticed a very strange behaviour (with JBOSS AS 6) with Message-Driven-Beans where we inject EJB.
> If the JMS queue is empty when the jboss server is started, then everything works fine.
> If, no luck, the jms queue is *NOT* empty, my MDB is apparently mounted *BEFORE* the ejb's
> and the @Inject failed:
> => "Failure WELD-000079 Could not find the EJB in JNDI:  class xxx"
> I further investigated the problem:
> I replaced the @Inject annotation, with a "manual" lookup of my ejb 
> using the javax.enterprise.inject.spi.BeanManager capabilities (that i put in a @Postcontruct method of my MDB), 
> The trick consisted in trying the lookup n times with a delay of x sec between each attempt.
> Here are the results (excerpt from server.log):
> {code:xml} 
> 2011-07-28 12:05:06,180 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [1] Trying to lookup KernelResources
> 2011-07-28 12:05:06,190 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [1] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:11,191 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [2] Trying to lookup KernelResources
> 2011-07-28 12:05:11,192 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [2] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:16,193 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [3] Trying to lookup KernelResources
> 2011-07-28 12:05:16,193 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [3] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:21,194 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [4] Trying to lookup KernelResources
> 2011-07-28 12:05:21,194 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [4] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:26,195 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [5] Trying to lookup KernelResources
> 2011-07-28 12:05:26,195 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [5] Failure WELD-000079 Could not find the EJB in JNDI:  class net.haulogy.energycomm.kernel.org$jboss$weld$bean-jboss$classloader:id="vfs:$$$Users$bli$Devware$jboss-6$0$0$Dev$server$default$deploy$energycomm-ear$ear"-SessionBean-KernelResources_$$_WeldProxy
> ...
> 2011-07-28 12:05:26,215 INFO  [org.jboss.ejb3.nointerface.impl.jndi.AbstractNoInterfaceViewBinder] (Thread-3) Binding the following entry in Global JNDI for bean:KernelResources
> => finally the EJB is bound !
> 2011-07-28 12:05:31,196 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** [6] Trying to lookup KernelResources
> 2011-07-28 12:05:31,197 INFO  [STDOUT] (Thread-0 (group:HornetQ-client-global-threads-183899831)) *** KernelResources = No-Interface view for endpoint [ jboss.j2ee:ear=energycomm-ear.ear,jar=energycomm-kernel-0.5.0-SNAPSHOT.jar,name=KernelResources,service=EJB3 ]
> => the 6th attempt now works :-)
> {code} 
> Conclusion: according to me, there is no doubt: dependencies between MDB's and EJB's are not correctly managed by the app server.
> The app server should wait for all EJB's to be bound before activating the MDB.
> MDB are activated too early (especially when jms queue is not empty at starttime)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 11:10:23 2011
From: jira-events at lists.jboss.org (Heiko Rupp (JIRA))
Date: Fri, 29 Jul 2011 11:10:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1430) Creation of
 server-groups with invalid parameters succeeds
Message-ID: <1159288518.91982.1311952223665.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Creation of server-groups with invalid parameters succeeds
----------------------------------------------------------

                 Key: AS7-1430
                 URL: https://issues.jboss.org/browse/AS7-1430
             Project: Application Server 7
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 7.0.0.Final
            Reporter: Heiko Rupp
            Assignee: Brian Stansberry


[domain at localhost:9999 subsystem=infinispan] /server-group=bla:add(profile="asdfjasdklfjasklfj",socket-binding-group=asfasdfjaslfhjk)
{
    "outcome" => "success",
    "result" => {
        "domain-results" => {"step-1" => undefined},
        "server-operations" => undefined
    }
}

Clearly the profile and socket-binding-group are invalid - the operation still succeeds

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 11:12:23 2011
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 29 Jul 2011 11:12:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBJCA-637) DataSource support
In-Reply-To: <1011027992.83055.1311701063649.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <873417580.91987.1311952343641.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-637.
-----------------------------------

    Resolution: Done


> DataSource support
> ------------------
>
>                 Key: JBJCA-637
>                 URL: https://issues.jboss.org/browse/JBJCA-637
>             Project: IronJacamar
>          Issue Type: Task
>          Components: Common, Deployer, JDBC
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.2.Final, 1.1.0.Alpha1
>
>
> We should support <datasource> deployments based on a javax.sql.DataSource instance.
> Add <datasource-class> to <datasource> and <driver> as optional.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 11:18:23 2011
From: jira-events at lists.jboss.org (Paul Gier (JIRA))
Date: Fri, 29 Jul 2011 11:18:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBBUILD-689) Add JGit repository
 to Maven repository
In-Reply-To: <1031274966.79166.1311588563657.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <281156675.91995.1311952703630.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBBUILD-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Gier closed JBBUILD-689.
-----------------------------

    Resolution: Done


I have added the new proxy repository, and added it to the public repo group.
The new repo is called JGit Releases

> Add JGit repository to Maven repository
> ---------------------------------------
>
>                 Key: JBBUILD-689
>                 URL: https://issues.jboss.org/browse/JBBUILD-689
>             Project: JBoss Build System
>          Issue Type: Feature Request
>          Components: Artifact Repositories
>            Reporter: Karel Piwko
>            Assignee: Paul Gier
>             Fix For: Build Support 2011
>
>
> Please add repository [1] to our Nexus instance. I'm using
> this dependency in Arquillian OpenShift Express container and
> having a extra repository defined in pom is not a way how we should do
> it.
> {code}
> <repositories>
>     <repository>
>         <id>jgit-repository</id>
>         <url>http://download.eclipse.org/jgit/maven</url>
>     </repository>
> </repositories>
> {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 11:35:23 2011
From: jira-events at lists.jboss.org (Emanuel Muckenhuber (JIRA))
Date: Fri, 29 Jul 2011 11:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1421) Modcluster subsystem
 has broken :read-resource-description
In-Reply-To: <1749021724.86448.1311792443737.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <492791219.92009.1311953723938.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Emanuel Muckenhuber reassigned AS7-1421:
----------------------------------------

    Assignee: Jean-Frederic Clere  (was: Brian Stansberry)


> Modcluster subsystem has broken :read-resource-description
> ----------------------------------------------------------
>
>                 Key: AS7-1421
>                 URL: https://issues.jboss.org/browse/AS7-1421
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.0.0.Final
>            Reporter: Heiko Rupp
>            Assignee: Jean-Frederic Clere
>
> [domain at localhost:9999 subsystem=modcluster] :read-resource-description
> {
>     "outcome" => "success",
>     "result" => {
>         "description" => "The configuration of the modcluster subsystem.",
>         "head-comment-allowed" => true,
>         "tail-comment-allowed" => true,
>         "namespace" => "urn:jboss:domain:modcluster:1.0",
>         "attributes" => {"mod-cluster-config" => {
>             "type" => OBJECT,
>             "description" => "The common modcluster configuration.",
>             "required" => false,
>             "access-type" => "read-only",
>             "storage" => "configuration"
>         }}
>     }
> }
> is not usable at all to use for management operations.
> Also attributes of mod-cluster-config should directly live in 'attributes'. There is no point in adding one more level here.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 11:39:24 2011
From: jira-events at lists.jboss.org (Bruno Georges (JIRA))
Date: Fri, 29 Jul 2011 11:39:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1141)
 LoadBalancePolicy that tries to pin all requests associated with a tx to
 one server
In-Reply-To: <31756017.1196688771620.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <547777445.92033.1311953964275.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/EJBTHREE-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bruno Georges reassigned EJBTHREE-1141:
---------------------------------------

    Assignee: Paul Ferraro


> LoadBalancePolicy that tries to pin all requests associated with a tx to one server
> -----------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1141
>                 URL: https://issues.jboss.org/browse/EJBTHREE-1141
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Galder Zamarre?o
>            Assignee: Paul Ferraro
>
> Create EJB3 transaction sticky load balance policies.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Fri Jul 29 11:39:24 2011
From: jira-events at lists.jboss.org (Bruno Georges (JIRA))
Date: Fri, 29 Jul 2011 11:39:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-1137)
 ClusterChooserInterceptor does not support transaction failover
 authorisations
In-Reply-To: <19574518.1196189446790.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1908855131.92036.1311953964408.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/EJBTHREE-1137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bruno Georges reassigned EJBTHREE-1137:
---------------------------------------

    Assignee: Paul Ferraro  (was: Galder Zamarre?o)


> ClusterChooserInterceptor does not support transaction failover authorisations
> ------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-1137
>                 URL: https://issues.jboss.org/browse/EJBTHREE-1137
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: AS 4.2.2.GA, AS 5.0.0.Beta3
>            Reporter: Galder Zamarre?o
>            Assignee: Paul Ferraro
>
> org.jboss.aspects.remoting.ClusterChooserInterceptor does not contain logic to 
> deal with transaction failover authorisations, contrary to legacy JRMP invoker or 
> Unified invoker.
> The reason I'm entering this as a bug rather than as a feature request is because
> not having such logic is allowing failovers when they shouldn't happen.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Fri Jul 29 11:50:23 2011
From: jira-events at lists.jboss.org (Andreas Tauber (JIRA))
Date: Fri, 29 Jul 2011 11:50:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1431) JBREM00205 when
	creating cluster
Message-ID: <1387022238.92081.1311954623655.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

JBREM00205 when creating cluster
--------------------------------

                 Key: AS7-1431
                 URL: https://issues.jboss.org/browse/AS7-1431
             Project: Application Server 7
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 7.0.0.Final
         Environment: 1 Windows XP + 1 Linux Host with jdk 1.6.0_26 each. I guess that a different enviroment won't change things. Why do you deliver Beta versions for xnio + remoting?
            Reporter: Andreas Tauber
            Assignee: Paul Ferraro


I try to setup cluster on two hosts using provided manual "Domain Setup". Host Controller on Windows XP can establish connection to Domain Controller on Linux because i see message:
Registered remote slave host staging.
But I can't see server instances on admin console. So, it seems like the Domain Controller is not able to connect back to native interface on Host Controller. Not really sure here.
Shutting down my host controller, I get warnings in boot.log. Here my complete boot.log:

17:05:58,484 INFO  [org.jboss.modules] (main) JBoss Modules version 1.0.1.GA
17:05:58,796 INFO  [org.jboss.msc] (main) JBoss MSC version 1.0.0.GA
17:05:59,156 INFO  [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 3.2.0.Beta2
17:05:59,171 INFO  [org.xnio] (MSC service thread 1-2) XNIO Version 3.0.0.Beta3
17:05:59,187 INFO  [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.0.0.Beta3
17:06:00,250 INFO  [org.jboss.as.remoting] (MSC service thread 1-1) Listening on /192.168.2.10:9999
17:06:04,468 WARN  [org.jboss.remoting.remote] (XNIO NIO Write 1) JBREM00205: Failed to accept a connection: java.nio.channels.ClosedChannelException
17:06:04,484 WARN  [org.jboss.remoting.remote] (XNIO NIO Write 1) JBREM00205: Failed to accept a connection: java.nio.channels.ClosedChannelException
17:06:04,484 WARN  [org.jboss.remoting.remote] (XNIO NIO Write 1) JBREM00205: Failed to accept a connection: java.nio.channels.ClosedChannelException
17:06:04,484 WARN  [org.jboss.remoting.remote] (XNIO NIO Write 1) JBREM00205: Failed to accept a connection: java.nio.channels.ClosedChannelException
17:06:04,484 WARN  [org.jboss.remoting.remote] (XNIO NIO Write 1) JBREM00205: Failed to accept a connection: java.nio.channels.ClosedChannelException
17:06:04,484 WARN  [org.jboss.remoting.remote] (XNIO NIO Write 1) JBREM00205: Failed to accept a connection: java.nio.channels.ClosedChannelException

Note: I renamed the servers to not create name clash (server-four, server-five, server-six) and disabled auto start because I wanted to start instances from admin console on domain controller. 



--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 14:38:23 2011
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 29 Jul 2011 14:38:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-9429)
 org.jboss.test.jbas8528.test.ApplicationNamingUnitTestCase.
In-Reply-To: <1400134153.91385.1311942744022.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <301138621.92497.1311964703631.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBAS-9429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shelly McGowan updated JBAS-9429:
---------------------------------


achive contents:
jbas8528.ear:
   102 Fri Jul 29 13:33:40 EDT 2011 META-INF/MANIFEST.MF
   534 Fri Jul 29 13:32:24 EDT 2011 META-INF/application.xml
   494 Fri Jul 29 13:33:42 EDT 2011 jbas8528.war

jbas8528.war
   102 Fri Jul 29 13:33:40 EDT 2011 META-INF/MANIFEST.MF
    67 Fri Jul 29 13:32:20 EDT 2011 index.jsp

application.xml:
    <application-name>jbas8528-overridden-appname</application-name>
    <module>
        <web>
            <web-uri>jbas8528.war</web-uri>
            <context-root>jbas8528-webapp</context-root>
        </web>
    </module>


> org.jboss.test.jbas8528.test.ApplicationNamingUnitTestCase.
> -----------------------------------------------------------
>
>                 Key: JBAS-9429
>                 URL: https://issues.jboss.org/browse/JBAS-9429
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: 6.1.0
>
>
> testApplicationDeployment:
> vfs:///mnt/hudson_workspace/workspace/JBoss-AS-6.1.x-testSuite-sun16/JBossAS/testsuite/output/lib/jbas8528.ear
> *** DEPLOYMENTS IN ERROR: Name -> Error
> vfs:///mnt/hudson_workspace/workspace/JBoss-AS-6.1.x-testSuite-sun16/JBossAS/testsuite/output/lib/jbas8528.ear -> org.jboss.deployers.spi.DeploymentException: Unable to find class path entry ClassPathEntryImpl{path=jbas8528.war/WEB-INF} from jbas8528.ear

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 14:53:23 2011
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 29 Jul 2011 14:53:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-3160) Using a custom
 Score is not possible because it's not posssible to hook in the custom
 ScoreCalculator
In-Reply-To: <815043993.91369.1311941603602.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <525404337.92521.1311965603714.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBRULES-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet resolved JBRULES-3160.
---------------------------------------

    Resolution: Done


Resolved on my fork of drools-planner (which will be merged ot master). Might or might not make 5.3, will definitely be in 5.4

> Using a custom Score is not possible because it's not posssible to hook in the custom ScoreCalculator
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3160
>                 URL: https://issues.jboss.org/browse/JBRULES-3160
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-planner
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>             Fix For: 5.3.0.Beta2
>
>
> See http://stackoverflow.com/questions/6625000/drools-creating-a-custom-score/6872867#6872867

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 14:59:23 2011
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Fri, 29 Jul 2011 14:59:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-2700) Allow setting a
 global variable (for example a service) which can be used by the score
 rules
In-Reply-To: <401582676.7221.1284738748577.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <860874135.92628.1311965963674.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617610#comment-12617610 ] 

Geoffrey De Smet commented on JBRULES-2700:
-------------------------------------------

One resolution would be the ability to hook in a WorkingMemoryPreperator, which is a class that would be run every time a new memory is created. The problem is you 'll probably want to be able to fetch those constants from some service that you need to inject in that Preperator, which would be hard...

I am not yet convinced that simply putting some InstitutionWeightings instance like in Examination example doesn't suffice :/

> Allow setting a global variable (for example a service) which can be used by the score rules
> --------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2700
>                 URL: https://issues.jboss.org/browse/JBRULES-2700
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-planner
>            Reporter: Wouter Horr?
>            Assignee: Geoffrey De Smet
>
> Currently, it is not possible to set a global variable in the working memory used by the solver. If a scoring rule needs an external helper for calculating scores (e.g. a dependency injected with OSGi DS), a workaround using a static variable in some class accessible by the scoring rules is needed.
> The easiest implementation is probably a new method in the Solver interface:
> public WorkingMemory getWorkingMemory();
> which provides access to the working memory used by the solver.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       


From jira-events at lists.jboss.org  Fri Jul 29 15:41:24 2011
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 29 Jul 2011 15:41:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-9426) org.jboss.jmx.test
	regressions
In-Reply-To: <531214594.90125.1311897263620.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1720560322.92862.1311968484789.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBAS-9426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617635#comment-12617635 ] 

Shelly McGowan commented on JBAS-9426:
--------------------------------------

This is the same issue seen in ApplicationNamingUnitTestCase; specifically,
nable to find class path entry ClassPathEntryImpl{path=dummy.war/WEB-INF} from invoker-adaptor-test.ear

> org.jboss.jmx.test regressions
> ------------------------------
>
>                 Key: JBAS-9426
>                 URL: https://issues.jboss.org/browse/JBAS-9426
>             Project: Legacy JBoss Application Server 6 
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: 6.1.0
>
>
> Tests affected:
> org.jboss.test.jmx.test.JMXConnectorUnitTestCase
> org.jboss.test.jmx.test.JMXInvokerUnitTestCase
> org.jboss.test.jmx.test.SecureJMXInvokerUnitTestCase

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 15:55:39 2011
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Fri, 29 Jul 2011 15:55:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1313) <distributable> web
 applications fail to deploy with the default configuration
In-Reply-To: <540578067.59906.1310987543621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1095931660.92912.1311969339023.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro resolved AS7-1313.
-------------------------------

    Fix Version/s: 7.0.1.Final
                   7.1.0.Alpha1
       Resolution: Done


> <distributable> web applications fail to deploy with the default configuration
> ------------------------------------------------------------------------------
>
>                 Key: AS7-1313
>                 URL: https://issues.jboss.org/browse/AS7-1313
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.0.0.Final
>            Reporter: Stuart Douglas
>            Assignee: Paul Ferraro
>             Fix For: 7.0.1.Final, 7.1.0.Alpha1
>
>
> <distributable> web applications fail with the following:
> "Services with missing/unavailable dependencies" => ["jboss.web.\"magnolia-bundled-webapp-4.4.4.war\" missing [ jboss.infinispan.web.___defaultcache ]"]}}}
> At the very least the user should get a better error message explaining why their deployment failed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Fri Jul 29 18:51:23 2011
From: jira-events at lists.jboss.org (dan ginsberg (JIRA))
Date: Fri, 29 Jul 2011 18:51:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1432) Adding director
 element to action-log in a virtual-host causes xml parse error
Message-ID: <644556071.93261.1311979883633.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Adding  director element to action-log in a virtual-host causes xml parse error
-------------------------------------------------------------------------------

                 Key: AS7-1432
                 URL: https://issues.jboss.org/browse/AS7-1432
             Project: Application Server 7
          Issue Type: Bug
          Components: Logging
    Affects Versions: 7.0.0.Final
         Environment: Linux x86_64
            Reporter: dan ginsberg
            Assignee: David Lloyd


In standalone.xml, in a virutal-server, 

1) add an access-log element
Find:  server starts correctly and creates the access log

2) in the access-log element, add a directory element
Find:  server no longer starts correctly.  you may see an xml parse error logged, or you may just find that subsequent xml is not correclty parsed

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 30 02:28:24 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Sat, 30 Jul 2011 02:28:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1433) CNFE for Hibernate
 4.0.0.Beta4: org.hibernate.hql.internal.ast.HqlToken
Message-ID: <1068095752.93311.1312007304082.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

CNFE for Hibernate 4.0.0.Beta4: org.hibernate.hql.internal.ast.HqlToken
-----------------------------------------------------------------------

                 Key: AS7-1433
                 URL: https://issues.jboss.org/browse/AS7-1433
             Project: Application Server 7
          Issue Type: Bug
          Components: JPA / Hibernate
    Affects Versions: 7.0.0.Final
         Environment: Jenkins build 1460
            Reporter: Juergen Zimmermann
            Assignee: Scott Marlow


I switched to Jenkins build 1460 which has Hibernate 4.0.0.Beta4. Now I'm getting the stacktrace below saying that org.hibernate.hql.internal.ast.HqlToken is not found. However, this class is in modules/org/hibernate/main/hibernate-core-4.0.0.Beta4.jar.

08:17:22,282 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/swaREST].[javax.ws.rs.core.Application]] (http--127.0.0.1-8080-1) Servlet.service() for servlet javax.ws.rs.core.Application threw exception: org.jboss.resteasy.spi.UnhandledException: javax.ejb.EJBTransactionRolledbackException: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
	at org.jboss.resteasy.core.SynchronousDispatcher.unwrapException(SynchronousDispatcher.java:345) [resteasy-jaxrs-2.2.1.GA.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:321) [resteasy-jaxrs-2.2.1.GA.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:214) [resteasy-jaxrs-2.2.1.GA.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:190) [resteasy-jaxrs-2.2.1.GA.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:534) [resteasy-jaxrs-2.2.1.GA.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:496) [resteasy-jaxrs-2.2.1.GA.jar:]
	at org.jboss.resteasy.core.AsynchronousDispatcher.invoke(AsynchronousDispatcher.java:243) [resteasy-jaxrs-2.2.1.GA.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:119) [resteasy-jaxrs-2.2.1.GA.jar:]
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.2.1.GA.jar:]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.2.1.GA.jar:]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.2.1.GA.jar:]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
	at java.lang.Thread.run(Thread.java:722) [:1.7.0]
Caused by: javax.ejb.EJBTransactionRolledbackException: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:158)
	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:237)
	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.required(CMTTxInterceptor.java:363)
	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:219)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:35)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
	at de.swa.kundenverwaltung.service.Kundenverwaltung$$$view74.findKundenByNachname(Unknown Source) [swaEJB.jar:]
	at de.swa.kundenverwaltung.rest.KundenverwaltungResourceImpl.findKunden(KundenverwaltungResourceImpl.java:94) [swaEJB.jar:]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:51)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
	at de.swa.util.LogInterceptor.log(LogInterceptor.java:79) [swaEJB.jar:]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:66)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:45) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewDescription$ComponentDispatcherInterceptor.processInvocation(ViewDescription.java:202)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:257)
	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.required(CMTTxInterceptor.java:359)
	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:219)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:35)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
	at de.swa.kundenverwaltung.rest.KundenverwaltungResource$$$view76.findKunden(Unknown Source) [swaEJB.jar:]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140) [resteasy-jaxrs-2.2.1.GA.jar:]
	at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:255) [resteasy-jaxrs-2.2.1.GA.jar:]
	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:220) [resteasy-jaxrs-2.2.1.GA.jar:]
	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:209) [resteasy-jaxrs-2.2.1.GA.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:519) [resteasy-jaxrs-2.2.1.GA.jar:]
	... 21 more
Caused by: java.lang.IllegalArgumentException: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
	at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1331)
	at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1277)
	at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:497)
	at org.hibernate.ejb.criteria.CriteriaQueryCompiler.compile(CriteriaQueryCompiler.java:227)
	at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:614)
	at org.jboss.as.jpa.container.AbstractEntityManager.createQuery(AbstractEntityManager.java:126) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
	at de.swa.kundenverwaltung.service.Kundenverwaltung.findKundenByNachname(Kundenverwaltung.java:138) [swaEJB.jar:]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:51)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
	at de.swa.util.LogInterceptor.log(LogInterceptor.java:79) [swaEJB.jar:]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:66)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:45) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewDescription$ComponentDispatcherInterceptor.processInvocation(ViewDescription.java:202)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:233)
	... 86 more
Caused by: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
	at org.hibernate.hql.internal.ast.HqlLexer.panic(HqlLexer.java:78)
	at antlr.CharScanner.setTokenObjectClass(CharScanner.java:338)
	at org.hibernate.hql.internal.ast.HqlLexer.setTokenObjectClass(HqlLexer.java:52)
	at antlr.CharScanner.<init>(CharScanner.java:49)
	at antlr.CharScanner.<init>(CharScanner.java:58)
	at org.hibernate.hql.internal.antlr.HqlBaseLexer.<init>(HqlBaseLexer.java:54)
	at org.hibernate.hql.internal.antlr.HqlBaseLexer.<init>(HqlBaseLexer.java:51)
	at org.hibernate.hql.internal.antlr.HqlBaseLexer.<init>(HqlBaseLexer.java:48)
	at org.hibernate.hql.internal.ast.HqlLexer.<init>(HqlLexer.java:47)
	at org.hibernate.hql.internal.ast.HqlParser.getInstance(HqlParser.java:67)
	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.parse(QueryTranslatorImpl.java:262)
	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:180)
	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:136)
	at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:101)
	at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:80)
	at org.hibernate.engine.query.spi.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:120)
	at org.hibernate.internal.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:214)
	at org.hibernate.internal.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:192)
	at org.hibernate.internal.SessionImpl.createQuery(SessionImpl.java:1527)
	at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:479)
	... 121 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 30 11:05:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Sat, 30 Jul 2011 11:05:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1433) CNFE for Hibernate
 4.0.0.Beta4: org.hibernate.hql.internal.ast.HqlToken
In-Reply-To: <1068095752.93311.1312007304082.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1034488826.93444.1312038323753.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617694#comment-12617694 ] 

Scott Marlow commented on AS7-1433:
-----------------------------------

HqlToken extends antlr.CommonToken which doesn't seem new.  The as7 "org.hibernate" module definition (as/modules/org/hibernate/main/module.xml), has a dependency on module "org.antlr" which contains antr.CommonToken.

Maybe the antlr-2.7.7 that "org.antlr" has is not new enough for the upgraded Hibernate.  No, that is not it.  https://github.com/hibernate/hibernate-core/blob/master/build.gradle shows that 2.7.7 is correct.

Maybe enabling AS7 trace logging (in as7/standalone/configuration/standalone.xml, change from "INFO" to "TRACE").  That should enable the as7 module classloader, to show more verbose output and might help determine the cause of the error.

Another approach, would be to try hacking up the as7/modules/org/hibernate/main folder to contain all of the Hibernate required jars (probably download the zip from http://sourceforge.net/projects/hibernate/files/hibernate4/4.0.0.Beta4/).  For each jar that you add, update modules.xml (add jar name to "resources" section and remove dependency for same jar from "dependencies").  Not all jars are covered currently by "dependencies", just ones like "org.antlr".



> CNFE for Hibernate 4.0.0.Beta4: org.hibernate.hql.internal.ast.HqlToken
> -----------------------------------------------------------------------
>
>                 Key: AS7-1433
>                 URL: https://issues.jboss.org/browse/AS7-1433
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Final
>         Environment: Jenkins build 1460
>            Reporter: Juergen Zimmermann
>            Assignee: Scott Marlow
>
> I switched to Jenkins build 1460 which has Hibernate 4.0.0.Beta4. Now I'm getting the stacktrace below saying that org.hibernate.hql.internal.ast.HqlToken is not found. However, this class is in modules/org/hibernate/main/hibernate-core-4.0.0.Beta4.jar.
> 08:17:22,282 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/swaREST].[javax.ws.rs.core.Application]] (http--127.0.0.1-8080-1) Servlet.service() for servlet javax.ws.rs.core.Application threw exception: org.jboss.resteasy.spi.UnhandledException: javax.ejb.EJBTransactionRolledbackException: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.unwrapException(SynchronousDispatcher.java:345) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:321) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:214) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:190) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:534) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:496) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.AsynchronousDispatcher.invoke(AsynchronousDispatcher.java:243) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:119) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:722) [:1.7.0]
> Caused by: javax.ejb.EJBTransactionRolledbackException: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:158)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:237)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.required(CMTTxInterceptor.java:363)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:219)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:35)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
> 	at de.swa.kundenverwaltung.service.Kundenverwaltung$$$view74.findKundenByNachname(Unknown Source) [swaEJB.jar:]
> 	at de.swa.kundenverwaltung.rest.KundenverwaltungResourceImpl.findKunden(KundenverwaltungResourceImpl.java:94) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
> 	at de.swa.util.LogInterceptor.log(LogInterceptor.java:79) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:45) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$ComponentDispatcherInterceptor.processInvocation(ViewDescription.java:202)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:257)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.required(CMTTxInterceptor.java:359)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:219)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:35)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
> 	at de.swa.kundenverwaltung.rest.KundenverwaltungResource$$$view76.findKunden(Unknown Source) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:255) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:220) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:209) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:519) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	... 21 more
> Caused by: java.lang.IllegalArgumentException: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1331)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1277)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:497)
> 	at org.hibernate.ejb.criteria.CriteriaQueryCompiler.compile(CriteriaQueryCompiler.java:227)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:614)
> 	at org.jboss.as.jpa.container.AbstractEntityManager.createQuery(AbstractEntityManager.java:126) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at de.swa.kundenverwaltung.service.Kundenverwaltung.findKundenByNachname(Kundenverwaltung.java:138) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
> 	at de.swa.util.LogInterceptor.log(LogInterceptor.java:79) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:45) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$ComponentDispatcherInterceptor.processInvocation(ViewDescription.java:202)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:233)
> 	... 86 more
> Caused by: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.hibernate.hql.internal.ast.HqlLexer.panic(HqlLexer.java:78)
> 	at antlr.CharScanner.setTokenObjectClass(CharScanner.java:338)
> 	at org.hibernate.hql.internal.ast.HqlLexer.setTokenObjectClass(HqlLexer.java:52)
> 	at antlr.CharScanner.<init>(CharScanner.java:49)
> 	at antlr.CharScanner.<init>(CharScanner.java:58)
> 	at org.hibernate.hql.internal.antlr.HqlBaseLexer.<init>(HqlBaseLexer.java:54)
> 	at org.hibernate.hql.internal.antlr.HqlBaseLexer.<init>(HqlBaseLexer.java:51)
> 	at org.hibernate.hql.internal.antlr.HqlBaseLexer.<init>(HqlBaseLexer.java:48)
> 	at org.hibernate.hql.internal.ast.HqlLexer.<init>(HqlLexer.java:47)
> 	at org.hibernate.hql.internal.ast.HqlParser.getInstance(HqlParser.java:67)
> 	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.parse(QueryTranslatorImpl.java:262)
> 	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:180)
> 	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:136)
> 	at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:101)
> 	at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:80)
> 	at org.hibernate.engine.query.spi.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:120)
> 	at org.hibernate.internal.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:214)
> 	at org.hibernate.internal.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:192)
> 	at org.hibernate.internal.SessionImpl.createQuery(SessionImpl.java:1527)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:479)
> 	... 121 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 30 13:18:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Sat, 30 Jul 2011 13:18:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1433) CNFE for Hibernate
 4.0.0.Beta4: org.hibernate.hql.internal.ast.HqlToken
In-Reply-To: <1068095752.93311.1312007304082.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <390388839.93458.1312046303677.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated AS7-1433:
------------------------------

    Fix Version/s: 7.0.1.Final


> CNFE for Hibernate 4.0.0.Beta4: org.hibernate.hql.internal.ast.HqlToken
> -----------------------------------------------------------------------
>
>                 Key: AS7-1433
>                 URL: https://issues.jboss.org/browse/AS7-1433
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Final
>         Environment: Jenkins build 1460
>            Reporter: Juergen Zimmermann
>            Assignee: Scott Marlow
>             Fix For: 7.0.1.Final
>
>
> I switched to Jenkins build 1460 which has Hibernate 4.0.0.Beta4. Now I'm getting the stacktrace below saying that org.hibernate.hql.internal.ast.HqlToken is not found. However, this class is in modules/org/hibernate/main/hibernate-core-4.0.0.Beta4.jar.
> 08:17:22,282 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/swaREST].[javax.ws.rs.core.Application]] (http--127.0.0.1-8080-1) Servlet.service() for servlet javax.ws.rs.core.Application threw exception: org.jboss.resteasy.spi.UnhandledException: javax.ejb.EJBTransactionRolledbackException: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.unwrapException(SynchronousDispatcher.java:345) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:321) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:214) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:190) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:534) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:496) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.AsynchronousDispatcher.invoke(AsynchronousDispatcher.java:243) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:119) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:722) [:1.7.0]
> Caused by: javax.ejb.EJBTransactionRolledbackException: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:158)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:237)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.required(CMTTxInterceptor.java:363)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:219)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:35)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
> 	at de.swa.kundenverwaltung.service.Kundenverwaltung$$$view74.findKundenByNachname(Unknown Source) [swaEJB.jar:]
> 	at de.swa.kundenverwaltung.rest.KundenverwaltungResourceImpl.findKunden(KundenverwaltungResourceImpl.java:94) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
> 	at de.swa.util.LogInterceptor.log(LogInterceptor.java:79) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:45) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$ComponentDispatcherInterceptor.processInvocation(ViewDescription.java:202)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:257)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.required(CMTTxInterceptor.java:359)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:219)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:35)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
> 	at de.swa.kundenverwaltung.rest.KundenverwaltungResource$$$view76.findKunden(Unknown Source) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:255) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:220) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:209) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:519) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	... 21 more
> Caused by: java.lang.IllegalArgumentException: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1331)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1277)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:497)
> 	at org.hibernate.ejb.criteria.CriteriaQueryCompiler.compile(CriteriaQueryCompiler.java:227)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:614)
> 	at org.jboss.as.jpa.container.AbstractEntityManager.createQuery(AbstractEntityManager.java:126) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at de.swa.kundenverwaltung.service.Kundenverwaltung.findKundenByNachname(Kundenverwaltung.java:138) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
> 	at de.swa.util.LogInterceptor.log(LogInterceptor.java:79) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:45) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$ComponentDispatcherInterceptor.processInvocation(ViewDescription.java:202)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:233)
> 	... 86 more
> Caused by: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.hibernate.hql.internal.ast.HqlLexer.panic(HqlLexer.java:78)
> 	at antlr.CharScanner.setTokenObjectClass(CharScanner.java:338)
> 	at org.hibernate.hql.internal.ast.HqlLexer.setTokenObjectClass(HqlLexer.java:52)
> 	at antlr.CharScanner.<init>(CharScanner.java:49)
> 	at antlr.CharScanner.<init>(CharScanner.java:58)
> 	at org.hibernate.hql.internal.antlr.HqlBaseLexer.<init>(HqlBaseLexer.java:54)
> 	at org.hibernate.hql.internal.antlr.HqlBaseLexer.<init>(HqlBaseLexer.java:51)
> 	at org.hibernate.hql.internal.antlr.HqlBaseLexer.<init>(HqlBaseLexer.java:48)
> 	at org.hibernate.hql.internal.ast.HqlLexer.<init>(HqlLexer.java:47)
> 	at org.hibernate.hql.internal.ast.HqlParser.getInstance(HqlParser.java:67)
> 	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.parse(QueryTranslatorImpl.java:262)
> 	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:180)
> 	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:136)
> 	at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:101)
> 	at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:80)
> 	at org.hibernate.engine.query.spi.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:120)
> 	at org.hibernate.internal.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:214)
> 	at org.hibernate.internal.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:192)
> 	at org.hibernate.internal.SessionImpl.createQuery(SessionImpl.java:1527)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:479)
> 	... 121 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 30 14:31:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Sat, 30 Jul 2011 14:31:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1433) CNFE for Hibernate
 4.0.0.Beta4: org.hibernate.hql.internal.ast.HqlToken
In-Reply-To: <1068095752.93311.1312007304082.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <457526480.93468.1312050683793.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617698#comment-12617698 ] 

Juergen Zimmermann commented on AS7-1433:
-----------------------------------------

It's just antlr:
When I copy antl-2.7.7.jar into modules/org/hibernate/main and replace in module.xml the <module> entry by a <resource-root> entry inside <resources>, then the issue is gone.

> CNFE for Hibernate 4.0.0.Beta4: org.hibernate.hql.internal.ast.HqlToken
> -----------------------------------------------------------------------
>
>                 Key: AS7-1433
>                 URL: https://issues.jboss.org/browse/AS7-1433
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Final
>         Environment: Jenkins build 1460
>            Reporter: Juergen Zimmermann
>            Assignee: Scott Marlow
>             Fix For: 7.0.1.Final
>
>
> I switched to Jenkins build 1460 which has Hibernate 4.0.0.Beta4. Now I'm getting the stacktrace below saying that org.hibernate.hql.internal.ast.HqlToken is not found. However, this class is in modules/org/hibernate/main/hibernate-core-4.0.0.Beta4.jar.
> 08:17:22,282 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/swaREST].[javax.ws.rs.core.Application]] (http--127.0.0.1-8080-1) Servlet.service() for servlet javax.ws.rs.core.Application threw exception: org.jboss.resteasy.spi.UnhandledException: javax.ejb.EJBTransactionRolledbackException: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.unwrapException(SynchronousDispatcher.java:345) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:321) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:214) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:190) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:534) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:496) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.AsynchronousDispatcher.invoke(AsynchronousDispatcher.java:243) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:119) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:722) [:1.7.0]
> Caused by: javax.ejb.EJBTransactionRolledbackException: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:158)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:237)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.required(CMTTxInterceptor.java:363)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:219)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:35)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
> 	at de.swa.kundenverwaltung.service.Kundenverwaltung$$$view74.findKundenByNachname(Unknown Source) [swaEJB.jar:]
> 	at de.swa.kundenverwaltung.rest.KundenverwaltungResourceImpl.findKunden(KundenverwaltungResourceImpl.java:94) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
> 	at de.swa.util.LogInterceptor.log(LogInterceptor.java:79) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:45) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$ComponentDispatcherInterceptor.processInvocation(ViewDescription.java:202)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:257)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.required(CMTTxInterceptor.java:359)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:219)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:35)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
> 	at de.swa.kundenverwaltung.rest.KundenverwaltungResource$$$view76.findKunden(Unknown Source) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:255) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:220) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:209) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:519) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	... 21 more
> Caused by: java.lang.IllegalArgumentException: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1331)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1277)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:497)
> 	at org.hibernate.ejb.criteria.CriteriaQueryCompiler.compile(CriteriaQueryCompiler.java:227)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:614)
> 	at org.jboss.as.jpa.container.AbstractEntityManager.createQuery(AbstractEntityManager.java:126) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at de.swa.kundenverwaltung.service.Kundenverwaltung.findKundenByNachname(Kundenverwaltung.java:138) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
> 	at de.swa.util.LogInterceptor.log(LogInterceptor.java:79) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:45) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$ComponentDispatcherInterceptor.processInvocation(ViewDescription.java:202)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:233)
> 	... 86 more
> Caused by: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.hibernate.hql.internal.ast.HqlLexer.panic(HqlLexer.java:78)
> 	at antlr.CharScanner.setTokenObjectClass(CharScanner.java:338)
> 	at org.hibernate.hql.internal.ast.HqlLexer.setTokenObjectClass(HqlLexer.java:52)
> 	at antlr.CharScanner.<init>(CharScanner.java:49)
> 	at antlr.CharScanner.<init>(CharScanner.java:58)
> 	at org.hibernate.hql.internal.antlr.HqlBaseLexer.<init>(HqlBaseLexer.java:54)
> 	at org.hibernate.hql.internal.antlr.HqlBaseLexer.<init>(HqlBaseLexer.java:51)
> 	at org.hibernate.hql.internal.antlr.HqlBaseLexer.<init>(HqlBaseLexer.java:48)
> 	at org.hibernate.hql.internal.ast.HqlLexer.<init>(HqlLexer.java:47)
> 	at org.hibernate.hql.internal.ast.HqlParser.getInstance(HqlParser.java:67)
> 	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.parse(QueryTranslatorImpl.java:262)
> 	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:180)
> 	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:136)
> 	at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:101)
> 	at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:80)
> 	at org.hibernate.engine.query.spi.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:120)
> 	at org.hibernate.internal.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:214)
> 	at org.hibernate.internal.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:192)
> 	at org.hibernate.internal.SessionImpl.createQuery(SessionImpl.java:1527)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:479)
> 	... 121 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 30 20:28:23 2011
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sat, 30 Jul 2011 20:28:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1434) Add support for
 measurement units to attribute and operation parameter description
Message-ID: <86525928.93488.1312072103623.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Add support for measurement units to attribute and operation parameter description
----------------------------------------------------------------------------------

                 Key: AS7-1434
                 URL: https://issues.jboss.org/browse/AS7-1434
             Project: Application Server 7
          Issue Type: Feature Request
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 7.0.1.Final, 7.1.0.Alpha1


Add an org.jboss.as.controller.client.helpers.MeasurementUnit enum to controller-client module. Add support for it to the controller module's AttributeDefinition class. Document it's use as the expected set of values for the 'unit' metadata for resource attribute, operation parameter, and operation return value descriptions in the detyped management API metadata.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 30 21:57:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Sat, 30 Jul 2011 21:57:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1433) CNFE for Hibernate
 4.0.0.Beta4: org.hibernate.hql.internal.ast.HqlToken
In-Reply-To: <1068095752.93311.1312007304082.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1147417877.93494.1312077443753.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617700#comment-12617700 ] 

Scott Marlow commented on AS7-1433:
-----------------------------------

Did you copy antl-2.7.7.jar from the as/modules/org/antlr/main folder?  I assume yes, since it is a convenient place to find it.  I find it very unlikely that something is wrong with the antlr module jar but wanted to ask anyway.

> CNFE for Hibernate 4.0.0.Beta4: org.hibernate.hql.internal.ast.HqlToken
> -----------------------------------------------------------------------
>
>                 Key: AS7-1433
>                 URL: https://issues.jboss.org/browse/AS7-1433
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Final
>         Environment: Jenkins build 1460
>            Reporter: Juergen Zimmermann
>            Assignee: Scott Marlow
>             Fix For: 7.0.1.Final
>
>
> I switched to Jenkins build 1460 which has Hibernate 4.0.0.Beta4. Now I'm getting the stacktrace below saying that org.hibernate.hql.internal.ast.HqlToken is not found. However, this class is in modules/org/hibernate/main/hibernate-core-4.0.0.Beta4.jar.
> 08:17:22,282 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/swaREST].[javax.ws.rs.core.Application]] (http--127.0.0.1-8080-1) Servlet.service() for servlet javax.ws.rs.core.Application threw exception: org.jboss.resteasy.spi.UnhandledException: javax.ejb.EJBTransactionRolledbackException: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.unwrapException(SynchronousDispatcher.java:345) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:321) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:214) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:190) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:534) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:496) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.AsynchronousDispatcher.invoke(AsynchronousDispatcher.java:243) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:119) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:722) [:1.7.0]
> Caused by: javax.ejb.EJBTransactionRolledbackException: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:158)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:237)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.required(CMTTxInterceptor.java:363)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:219)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:35)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
> 	at de.swa.kundenverwaltung.service.Kundenverwaltung$$$view74.findKundenByNachname(Unknown Source) [swaEJB.jar:]
> 	at de.swa.kundenverwaltung.rest.KundenverwaltungResourceImpl.findKunden(KundenverwaltungResourceImpl.java:94) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
> 	at de.swa.util.LogInterceptor.log(LogInterceptor.java:79) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:45) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$ComponentDispatcherInterceptor.processInvocation(ViewDescription.java:202)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:257)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.required(CMTTxInterceptor.java:359)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:219)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:35)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
> 	at de.swa.kundenverwaltung.rest.KundenverwaltungResource$$$view76.findKunden(Unknown Source) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:255) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:220) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:209) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:519) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	... 21 more
> Caused by: java.lang.IllegalArgumentException: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1331)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1277)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:497)
> 	at org.hibernate.ejb.criteria.CriteriaQueryCompiler.compile(CriteriaQueryCompiler.java:227)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:614)
> 	at org.jboss.as.jpa.container.AbstractEntityManager.createQuery(AbstractEntityManager.java:126) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at de.swa.kundenverwaltung.service.Kundenverwaltung.findKundenByNachname(Kundenverwaltung.java:138) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
> 	at de.swa.util.LogInterceptor.log(LogInterceptor.java:79) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:45) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$ComponentDispatcherInterceptor.processInvocation(ViewDescription.java:202)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:233)
> 	... 86 more
> Caused by: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.hibernate.hql.internal.ast.HqlLexer.panic(HqlLexer.java:78)
> 	at antlr.CharScanner.setTokenObjectClass(CharScanner.java:338)
> 	at org.hibernate.hql.internal.ast.HqlLexer.setTokenObjectClass(HqlLexer.java:52)
> 	at antlr.CharScanner.<init>(CharScanner.java:49)
> 	at antlr.CharScanner.<init>(CharScanner.java:58)
> 	at org.hibernate.hql.internal.antlr.HqlBaseLexer.<init>(HqlBaseLexer.java:54)
> 	at org.hibernate.hql.internal.antlr.HqlBaseLexer.<init>(HqlBaseLexer.java:51)
> 	at org.hibernate.hql.internal.antlr.HqlBaseLexer.<init>(HqlBaseLexer.java:48)
> 	at org.hibernate.hql.internal.ast.HqlLexer.<init>(HqlLexer.java:47)
> 	at org.hibernate.hql.internal.ast.HqlParser.getInstance(HqlParser.java:67)
> 	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.parse(QueryTranslatorImpl.java:262)
> 	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:180)
> 	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:136)
> 	at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:101)
> 	at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:80)
> 	at org.hibernate.engine.query.spi.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:120)
> 	at org.hibernate.internal.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:214)
> 	at org.hibernate.internal.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:192)
> 	at org.hibernate.internal.SessionImpl.createQuery(SessionImpl.java:1527)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:479)
> 	... 121 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sat Jul 30 23:14:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Sat, 30 Jul 2011 23:14:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1433) CNFE for Hibernate
 4.0.0.Beta4: org.hibernate.hql.internal.ast.HqlToken
In-Reply-To: <1068095752.93311.1312007304082.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1912324093.93499.1312082063780.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617701#comment-12617701 ] 

Juergen Zimmermann commented on AS7-1433:
-----------------------------------------

No, I copied it from Sourceforge's Hibernate distribution.

> CNFE for Hibernate 4.0.0.Beta4: org.hibernate.hql.internal.ast.HqlToken
> -----------------------------------------------------------------------
>
>                 Key: AS7-1433
>                 URL: https://issues.jboss.org/browse/AS7-1433
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Final
>         Environment: Jenkins build 1460
>            Reporter: Juergen Zimmermann
>            Assignee: Scott Marlow
>             Fix For: 7.0.1.Final
>
>
> I switched to Jenkins build 1460 which has Hibernate 4.0.0.Beta4. Now I'm getting the stacktrace below saying that org.hibernate.hql.internal.ast.HqlToken is not found. However, this class is in modules/org/hibernate/main/hibernate-core-4.0.0.Beta4.jar.
> 08:17:22,282 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/swaREST].[javax.ws.rs.core.Application]] (http--127.0.0.1-8080-1) Servlet.service() for servlet javax.ws.rs.core.Application threw exception: org.jboss.resteasy.spi.UnhandledException: javax.ejb.EJBTransactionRolledbackException: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.unwrapException(SynchronousDispatcher.java:345) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:321) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:214) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:190) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:534) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:496) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.AsynchronousDispatcher.invoke(AsynchronousDispatcher.java:243) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:119) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:722) [:1.7.0]
> Caused by: javax.ejb.EJBTransactionRolledbackException: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:158)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:237)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.required(CMTTxInterceptor.java:363)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:219)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:35)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
> 	at de.swa.kundenverwaltung.service.Kundenverwaltung$$$view74.findKundenByNachname(Unknown Source) [swaEJB.jar:]
> 	at de.swa.kundenverwaltung.rest.KundenverwaltungResourceImpl.findKunden(KundenverwaltungResourceImpl.java:94) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
> 	at de.swa.util.LogInterceptor.log(LogInterceptor.java:79) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:45) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$ComponentDispatcherInterceptor.processInvocation(ViewDescription.java:202)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:257)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.required(CMTTxInterceptor.java:359)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:219)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:35)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
> 	at de.swa.kundenverwaltung.rest.KundenverwaltungResource$$$view76.findKunden(Unknown Source) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:255) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:220) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:209) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:519) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	... 21 more
> Caused by: java.lang.IllegalArgumentException: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1331)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1277)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:497)
> 	at org.hibernate.ejb.criteria.CriteriaQueryCompiler.compile(CriteriaQueryCompiler.java:227)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:614)
> 	at org.jboss.as.jpa.container.AbstractEntityManager.createQuery(AbstractEntityManager.java:126) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at de.swa.kundenverwaltung.service.Kundenverwaltung.findKundenByNachname(Kundenverwaltung.java:138) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
> 	at de.swa.util.LogInterceptor.log(LogInterceptor.java:79) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:45) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$ComponentDispatcherInterceptor.processInvocation(ViewDescription.java:202)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:233)
> 	... 86 more
> Caused by: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.hibernate.hql.internal.ast.HqlLexer.panic(HqlLexer.java:78)
> 	at antlr.CharScanner.setTokenObjectClass(CharScanner.java:338)
> 	at org.hibernate.hql.internal.ast.HqlLexer.setTokenObjectClass(HqlLexer.java:52)
> 	at antlr.CharScanner.<init>(CharScanner.java:49)
> 	at antlr.CharScanner.<init>(CharScanner.java:58)
> 	at org.hibernate.hql.internal.antlr.HqlBaseLexer.<init>(HqlBaseLexer.java:54)
> 	at org.hibernate.hql.internal.antlr.HqlBaseLexer.<init>(HqlBaseLexer.java:51)
> 	at org.hibernate.hql.internal.antlr.HqlBaseLexer.<init>(HqlBaseLexer.java:48)
> 	at org.hibernate.hql.internal.ast.HqlLexer.<init>(HqlLexer.java:47)
> 	at org.hibernate.hql.internal.ast.HqlParser.getInstance(HqlParser.java:67)
> 	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.parse(QueryTranslatorImpl.java:262)
> 	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:180)
> 	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:136)
> 	at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:101)
> 	at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:80)
> 	at org.hibernate.engine.query.spi.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:120)
> 	at org.hibernate.internal.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:214)
> 	at org.hibernate.internal.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:192)
> 	at org.hibernate.internal.SessionImpl.createQuery(SessionImpl.java:1527)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:479)
> 	... 121 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 31 03:14:23 2011
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Sun, 31 Jul 2011 03:14:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1433) CNFE for Hibernate
 4.0.0.Beta4: org.hibernate.hql.internal.ast.HqlToken
In-Reply-To: <1068095752.93311.1312007304082.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <291595255.93560.1312096463782.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617717#comment-12617717 ] 

Juergen Zimmermann commented on AS7-1433:
-----------------------------------------

When I copy antlr from the modules/... folder, then the issue is also gone.

> CNFE for Hibernate 4.0.0.Beta4: org.hibernate.hql.internal.ast.HqlToken
> -----------------------------------------------------------------------
>
>                 Key: AS7-1433
>                 URL: https://issues.jboss.org/browse/AS7-1433
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Final
>         Environment: Jenkins build 1460
>            Reporter: Juergen Zimmermann
>            Assignee: Scott Marlow
>             Fix For: 7.0.1.Final
>
>
> I switched to Jenkins build 1460 which has Hibernate 4.0.0.Beta4. Now I'm getting the stacktrace below saying that org.hibernate.hql.internal.ast.HqlToken is not found. However, this class is in modules/org/hibernate/main/hibernate-core-4.0.0.Beta4.jar.
> 08:17:22,282 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/swaREST].[javax.ws.rs.core.Application]] (http--127.0.0.1-8080-1) Servlet.service() for servlet javax.ws.rs.core.Application threw exception: org.jboss.resteasy.spi.UnhandledException: javax.ejb.EJBTransactionRolledbackException: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.unwrapException(SynchronousDispatcher.java:345) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:321) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:214) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:190) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:534) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:496) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.AsynchronousDispatcher.invoke(AsynchronousDispatcher.java:243) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:119) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:722) [:1.7.0]
> Caused by: javax.ejb.EJBTransactionRolledbackException: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:158)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:237)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.required(CMTTxInterceptor.java:363)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:219)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:35)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
> 	at de.swa.kundenverwaltung.service.Kundenverwaltung$$$view74.findKundenByNachname(Unknown Source) [swaEJB.jar:]
> 	at de.swa.kundenverwaltung.rest.KundenverwaltungResourceImpl.findKunden(KundenverwaltungResourceImpl.java:94) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
> 	at de.swa.util.LogInterceptor.log(LogInterceptor.java:79) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:45) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$ComponentDispatcherInterceptor.processInvocation(ViewDescription.java:202)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:257)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.required(CMTTxInterceptor.java:359)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:219)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:35)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
> 	at de.swa.kundenverwaltung.rest.KundenverwaltungResource$$$view76.findKunden(Unknown Source) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:255) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:220) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:209) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:519) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	... 21 more
> Caused by: java.lang.IllegalArgumentException: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1331)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1277)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:497)
> 	at org.hibernate.ejb.criteria.CriteriaQueryCompiler.compile(CriteriaQueryCompiler.java:227)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:614)
> 	at org.jboss.as.jpa.container.AbstractEntityManager.createQuery(AbstractEntityManager.java:126) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at de.swa.kundenverwaltung.service.Kundenverwaltung.findKundenByNachname(Kundenverwaltung.java:138) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
> 	at de.swa.util.LogInterceptor.log(LogInterceptor.java:79) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:45) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$ComponentDispatcherInterceptor.processInvocation(ViewDescription.java:202)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:233)
> 	... 86 more
> Caused by: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.hibernate.hql.internal.ast.HqlLexer.panic(HqlLexer.java:78)
> 	at antlr.CharScanner.setTokenObjectClass(CharScanner.java:338)
> 	at org.hibernate.hql.internal.ast.HqlLexer.setTokenObjectClass(HqlLexer.java:52)
> 	at antlr.CharScanner.<init>(CharScanner.java:49)
> 	at antlr.CharScanner.<init>(CharScanner.java:58)
> 	at org.hibernate.hql.internal.antlr.HqlBaseLexer.<init>(HqlBaseLexer.java:54)
> 	at org.hibernate.hql.internal.antlr.HqlBaseLexer.<init>(HqlBaseLexer.java:51)
> 	at org.hibernate.hql.internal.antlr.HqlBaseLexer.<init>(HqlBaseLexer.java:48)
> 	at org.hibernate.hql.internal.ast.HqlLexer.<init>(HqlLexer.java:47)
> 	at org.hibernate.hql.internal.ast.HqlParser.getInstance(HqlParser.java:67)
> 	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.parse(QueryTranslatorImpl.java:262)
> 	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:180)
> 	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:136)
> 	at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:101)
> 	at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:80)
> 	at org.hibernate.engine.query.spi.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:120)
> 	at org.hibernate.internal.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:214)
> 	at org.hibernate.internal.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:192)
> 	at org.hibernate.internal.SessionImpl.createQuery(SessionImpl.java:1527)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:479)
> 	... 121 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 31 04:16:24 2011
From: jira-events at lists.jboss.org (Radai Rosenblatt (JIRA))
Date: Sun, 31 Jul 2011 04:16:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-3161) CEP - event both
 in and out of time window at the same time
Message-ID: <382418999.93569.1312100184092.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

CEP - event both in and out of time window at the same time
-----------------------------------------------------------

                 Key: JBRULES-3161
                 URL: https://issues.jboss.org/browse/JBRULES-3161
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: drools-core
    Affects Versions: 5.2.0.Final
         Environment: jre 6u24, windows 7 x64
            Reporter: Radai Rosenblatt
            Assignee: Mark Proctor
            Priority: Critical


given this object:

public class Event {
    private Date started;
    private Date finished;
    private long duration;
    //getters and setters
}

the following drools code:

declare Event
    @role( event )
    @duration ( duration )
    @timestamp( started )
end

rule "Event Exists In Window"
when
    $eventOne : Event() over window:time( 1h ) from entry-point "Event Stream"
then
    //nothing
end

rule "No Event Exists In Window"
when
    not ( Event() over window:time( 1h ) from entry-point "Event Stream" )
then
    //nothing
end

and the following scenario:

      now-1.5h          the event             now+1h 
         |---------------------------------------|   
                   the window                        
              |------------------|                   
                                                     
---------------------------------|-------------> T   
                                now                  
(an event at time T that start at T-1.5h and ends at T+1h)

both of the above rules fire. im not sure which of them _should_ fire for this scenario, but im pretty sure its either one or the other (to my understanding the conditions are logically exclusive - there either exists an event in the window or there doesnt)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 31 04:20:23 2011
From: jira-events at lists.jboss.org (Radai Rosenblatt (JIRA))
Date: Sun, 31 Jul 2011 04:20:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-3161) CEP - event both
 in and out of time window at the same time
In-Reply-To: <382418999.93569.1312100184092.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1899995225.93574.1312100423671.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBRULES-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radai Rosenblatt updated JBRULES-3161:
--------------------------------------

    Attachment: illustration.jpg


this is the scenario im recreating in this bug

> CEP - event both in and out of time window at the same time
> -----------------------------------------------------------
>
>                 Key: JBRULES-3161
>                 URL: https://issues.jboss.org/browse/JBRULES-3161
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.2.0.Final
>         Environment: jre 6u24, windows 7 x64
>            Reporter: Radai Rosenblatt
>            Assignee: Mark Proctor
>            Priority: Critical
>         Attachments: illustration.jpg
>
>
> given this object:
> public class Event {
>     private Date started;
>     private Date finished;
>     private long duration;
>     //getters and setters
> }
> the following drools code:
> declare Event
>     @role( event )
>     @duration ( duration )
>     @timestamp( started )
> end
> rule "Event Exists In Window"
> when
>     $eventOne : Event() over window:time( 1h ) from entry-point "Event Stream"
> then
>     //nothing
> end
> rule "No Event Exists In Window"
> when
>     not ( Event() over window:time( 1h ) from entry-point "Event Stream" )
> then
>     //nothing
> end
> and the following scenario:
>       now-1.5h          the event             now+1h 
>          |---------------------------------------|   
>                    the window                        
>               |------------------|                   
>                                                      
> ---------------------------------|-------------> T   
>                                 now                  
> (an event at time T that start at T-1.5h and ends at T+1h)
> both of the above rules fire. im not sure which of them _should_ fire for this scenario, but im pretty sure its either one or the other (to my understanding the conditions are logically exclusive - there either exists an event in the window or there doesnt)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 31 04:22:23 2011
From: jira-events at lists.jboss.org (Radai Rosenblatt (JIRA))
Date: Sun, 31 Jul 2011 04:22:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-3161) CEP - event both
 in and out of time window at the same time
In-Reply-To: <382418999.93569.1312100184092.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1116850958.93578.1312100543839.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBRULES-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radai Rosenblatt updated JBRULES-3161:
--------------------------------------

    Attachment: droolsbug.zip


the maven project recreating the issue

> CEP - event both in and out of time window at the same time
> -----------------------------------------------------------
>
>                 Key: JBRULES-3161
>                 URL: https://issues.jboss.org/browse/JBRULES-3161
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.2.0.Final
>         Environment: jre 6u24, windows 7 x64
>            Reporter: Radai Rosenblatt
>            Assignee: Mark Proctor
>            Priority: Critical
>         Attachments: droolsbug.zip, illustration.jpg
>
>
> given this object:
> public class Event {
>     private Date started;
>     private Date finished;
>     private long duration;
>     //getters and setters
> }
> the following drools code:
> declare Event
>     @role( event )
>     @duration ( duration )
>     @timestamp( started )
> end
> rule "Event Exists In Window"
> when
>     $eventOne : Event() over window:time( 1h ) from entry-point "Event Stream"
> then
>     //nothing
> end
> rule "No Event Exists In Window"
> when
>     not ( Event() over window:time( 1h ) from entry-point "Event Stream" )
> then
>     //nothing
> end
> and the following scenario:
>       now-1.5h          the event             now+1h 
>          |---------------------------------------|   
>                    the window                        
>               |------------------|                   
>                                                      
> ---------------------------------|-------------> T   
>                                 now                  
> (an event at time T that start at T-1.5h and ends at T+1h)
> both of the above rules fire. im not sure which of them _should_ fire for this scenario, but im pretty sure its either one or the other (to my understanding the conditions are logically exclusive - there either exists an event in the window or there doesnt)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 31 04:22:24 2011
From: jira-events at lists.jboss.org (Radai Rosenblatt (JIRA))
Date: Sun, 31 Jul 2011 04:22:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-3161) CEP - event both
 in and out of time window at the same time
In-Reply-To: <382418999.93569.1312100184092.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2089527336.93582.1312100544007.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBRULES-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radai Rosenblatt updated JBRULES-3161:
--------------------------------------

    Description: 
given this object:

public class Event {
    private Date started;
    private Date finished;
    private long duration;
    //getters and setters
}

the following drools code:

declare Event
    @role( event )
    @duration ( duration )
    @timestamp( started )
end

rule "Event Exists In Window"
when
    $eventOne : Event() over window:time( 1h ) from entry-point "Event Stream"
then
    //nothing
end

rule "No Event Exists In Window"
when
    not ( Event() over window:time( 1h ) from entry-point "Event Stream" )
then
    //nothing
end

and the following scenario:

[miserable attempt at ascii art replaced by attached image]

(an event at time T that start at T-1.5h and ends at T+1h)

both of the above rules fire. im not sure which of them _should_ fire for this scenario, but im pretty sure its either one or the other (to my understanding the conditions are logically exclusive - there either exists an event in the window or there doesnt)

  was:
given this object:

public class Event {
    private Date started;
    private Date finished;
    private long duration;
    //getters and setters
}

the following drools code:

declare Event
    @role( event )
    @duration ( duration )
    @timestamp( started )
end

rule "Event Exists In Window"
when
    $eventOne : Event() over window:time( 1h ) from entry-point "Event Stream"
then
    //nothing
end

rule "No Event Exists In Window"
when
    not ( Event() over window:time( 1h ) from entry-point "Event Stream" )
then
    //nothing
end

and the following scenario:

      now-1.5h          the event             now+1h 
         |---------------------------------------|   
                   the window                        
              |------------------|                   
                                                     
---------------------------------|-------------> T   
                                now                  
(an event at time T that start at T-1.5h and ends at T+1h)

both of the above rules fire. im not sure which of them _should_ fire for this scenario, but im pretty sure its either one or the other (to my understanding the conditions are logically exclusive - there either exists an event in the window or there doesnt)



> CEP - event both in and out of time window at the same time
> -----------------------------------------------------------
>
>                 Key: JBRULES-3161
>                 URL: https://issues.jboss.org/browse/JBRULES-3161
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.2.0.Final
>         Environment: jre 6u24, windows 7 x64
>            Reporter: Radai Rosenblatt
>            Assignee: Mark Proctor
>            Priority: Critical
>         Attachments: droolsbug.zip, illustration.jpg
>
>
> given this object:
> public class Event {
>     private Date started;
>     private Date finished;
>     private long duration;
>     //getters and setters
> }
> the following drools code:
> declare Event
>     @role( event )
>     @duration ( duration )
>     @timestamp( started )
> end
> rule "Event Exists In Window"
> when
>     $eventOne : Event() over window:time( 1h ) from entry-point "Event Stream"
> then
>     //nothing
> end
> rule "No Event Exists In Window"
> when
>     not ( Event() over window:time( 1h ) from entry-point "Event Stream" )
> then
>     //nothing
> end
> and the following scenario:
> [miserable attempt at ascii art replaced by attached image]
> (an event at time T that start at T-1.5h and ends at T+1h)
> both of the above rules fire. im not sure which of them _should_ fire for this scenario, but im pretty sure its either one or the other (to my understanding the conditions are logically exclusive - there either exists an event in the window or there doesnt)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 31 04:41:23 2011
From: jira-events at lists.jboss.org (Rostislav Svoboda (JIRA))
Date: Sun, 31 Jul 2011 04:41:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (AS7-1435) Modify cobertura
 maven plugin definition to use version 2.5
Message-ID: <481198405.93585.1312101683624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Modify cobertura maven plugin definition to use version 2.5
-----------------------------------------------------------

                 Key: AS7-1435
                 URL: https://issues.jboss.org/browse/AS7-1435
             Project: Application Server 7
          Issue Type: Task
            Reporter: Rostislav Svoboda


Upgrade jboss-parent to use version 2.5 for cobertura maven plugin.
Version 2.5 contains functionality for agregated report - http://jira.codehaus.org/browse/MCOBERTURA-65


Don't use version 2.5.1 because there is NPE bug - see http://jira.codehaus.org/browse/MCOBERTURA-151


Workaround: specify cobertura plugin version from command line
  mvn -Pcode-coverage -Dcobertura.aggregate=true -Dversion.cobertura.plugin=2.5 clean cobertura:clean cobertura:cobertura

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 31 04:43:23 2011
From: jira-events at lists.jboss.org (Rostislav Svoboda (JIRA))
Date: Sun, 31 Jul 2011 04:43:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1435) Modify cobertura
 maven plugin definition to use version 2.5
In-Reply-To: <481198405.93585.1312101683624.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <925246037.93589.1312101803704.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rostislav Svoboda reassigned AS7-1435:
--------------------------------------

    Assignee: Paul Gier


Paul should be the right person.

> Modify cobertura maven plugin definition to use version 2.5
> -----------------------------------------------------------
>
>                 Key: AS7-1435
>                 URL: https://issues.jboss.org/browse/AS7-1435
>             Project: Application Server 7
>          Issue Type: Task
>            Reporter: Rostislav Svoboda
>            Assignee: Paul Gier
>
> Upgrade jboss-parent to use version 2.5 for cobertura maven plugin.
> Version 2.5 contains functionality for agregated report - http://jira.codehaus.org/browse/MCOBERTURA-65
> Don't use version 2.5.1 because there is NPE bug - see http://jira.codehaus.org/browse/MCOBERTURA-151
> Workaround: specify cobertura plugin version from command line
>   mvn -Pcode-coverage -Dcobertura.aggregate=true -Dversion.cobertura.plugin=2.5 clean cobertura:clean cobertura:cobertura

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 31 09:37:23 2011
From: jira-events at lists.jboss.org (Aslak Knutsen (JIRA))
Date: Sun, 31 Jul 2011 09:37:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1318)
 CommonContainerConfiguration should contain managementAddress
In-Reply-To: <997120400.60461.1310998703826.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1998865036.93644.1312119443954.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aslak Knutsen reassigned AS7-1318:
----------------------------------

    Assignee: Aslak Knutsen  (was: Andrew Rubinger)


> CommonContainerConfiguration should contain managementAddress
> -------------------------------------------------------------
>
>                 Key: AS7-1318
>                 URL: https://issues.jboss.org/browse/AS7-1318
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 7.0.0.Final
>            Reporter: Rostislav Svoboda
>            Assignee: Aslak Knutsen
>             Fix For: 7.1.0.Alpha1
>
>
> CommonContainerConfiguration (org.jboss.as.arquillian.container) should contain managementAddress.
> AS7 can be configured to use different IP addresses for management and public interface. 
> This could be problem for testing in remote mode.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 31 11:19:23 2011
From: jira-events at lists.jboss.org (Aslak Knutsen (JIRA))
Date: Sun, 31 Jul 2011 11:19:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1361) Arquillian AS7
 Container force a dependency on Arquillian Service in manifest.mf
In-Reply-To: <826629031.72440.1311253943849.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <120297192.93651.1312125563712.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aslak Knutsen reassigned AS7-1361:
----------------------------------

    Assignee: Aslak Knutsen  (was: Andrew Rubinger)


> Arquillian AS7 Container force a dependency on Arquillian Service in manifest.mf
> --------------------------------------------------------------------------------
>
>                 Key: AS7-1361
>                 URL: https://issues.jboss.org/browse/AS7-1361
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 7.0.0.Final
>            Reporter: Aslak Knutsen
>            Assignee: Aslak Knutsen
>             Fix For: 7.0.1.Final
>
>
> When trying to e.g. use the Servlet Protocol instead of the jmx-as7 protocol you will get the following exception:
> ["jboss.deployment.unit.\"624b14c4-2bb2-4d44-be9e-1168c4d29164.war\".CONFIGURE_MODULE missing [ jboss.module.information.service.\"deployment.arquillian-service\".main ]
> The AS7 container adds a dependency to the Arquillian Service using ApplicationArchiveProcessors which is a general purpose archive processor and it not tied to the Protocol itself. This handling needs to be moved to the DeploymentPackager.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 31 12:01:23 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Sun, 31 Jul 2011 12:01:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMESSAGING-1893) Using
 separate threads to stop message sucker
In-Reply-To: <1681405433.88423.1311858623682.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1448586440.93656.1312128083774.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao resolved JBMESSAGING-1893.
---------------------------------------

    Resolution: Done


> Using separate threads to stop message sucker
> ---------------------------------------------
>
>                 Key: JBMESSAGING-1893
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1893
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP14, 1.4.8.SP2
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> Stopping MessageSuckers involve remoting operations (such as close consumer) and that may take a long time blocking if the network has problems. Easpecially during failover, the stop of suckers are executed in the thread of jgroups, which doesn't expect any long blocking operations. It should be executed using separate threads (pool).
>  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 31 12:01:23 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Sun, 31 Jul 2011 12:01:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-1893) Using separate
 threads to stop message sucker
In-Reply-To: <1681405433.88423.1311858623682.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <248884617.93660.1312128083885.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao closed JBMESSAGING-1893.
-------------------------------------



> Using separate threads to stop message sucker
> ---------------------------------------------
>
>                 Key: JBMESSAGING-1893
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1893
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP14, 1.4.8.SP2
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3
>
>
> Stopping MessageSuckers involve remoting operations (such as close consumer) and that may take a long time blocking if the network has problems. Easpecially during failover, the stop of suckers are executed in the thread of jgroups, which doesn't expect any long blocking operations. It should be executed using separate threads (pool).
>  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 31 14:36:23 2011
From: jira-events at lists.jboss.org (Esteban Aliverti (JIRA))
Date: Sun, 31 Jul 2011 14:36:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-2800) Issue with
 literals in Drools Verifier 5.1.1
In-Reply-To: <123642794.1719.1289932905646.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <460218089.93672.1312137383958.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBRULES-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Esteban Aliverti updated JBRULES-2800:
--------------------------------------

    Attachment: JBRULES-2800-testProject.zip


Since to be working in 5.2.0.Final.
Could you please check it?

> Issue with literals in Drools Verifier 5.1.1
> --------------------------------------------
>
>                 Key: JBRULES-2800
>                 URL: https://issues.jboss.org/browse/JBRULES-2800
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-verifier
>    Affects Versions: 5.1.1.FINAL
>            Reporter: Nathan Bell
>            Assignee: Toni Rikkola
>            Priority: Minor
>         Attachments: JBRULES-2800-testProject.zip
>
>
> I posted this to the "rules-users" list, and did not get a response. That leads me to believe it is a bug, so I'm submitting it here. Below is the text of my email.
> Using org.drools.verifier found in "drools-verifier-5.1.1.jar" I get an org.drools.RuntimeDroolsException if a pattern in a rule LHS contains a comparison to a literal value using the equals operator.
> Please consider the following rule I created solely for the purposes of isolating this issue.
> package com.simple.test.rule
> import com.p1s.mps.rulevalidator.TestFact;
> rule "TestRule"
> when
>       $fact : TestFact(value == 1)
> then
>       System.out.println($fact.getValue());
> end
> The following class definition for the TestFact.
> package com.p1s.mps.rulevalidator;
> public class TestFact 
> {
>       private int value;
>       public TestFact(int value) {
>             this.value = value;
>       }
>       
>       public int getValue() {
>             return value;
>       }
>       public void setValue(int value) {
>             this.value = value;
>       }
>       @Override
>       public int hashCode() {
>             final int prime = 31;
>             int result = 1;
>             result = prime * result + value;
>             return result;
>       }
>       @Override
>       public boolean equals(Object obj) {
>             if (this == obj)
>                   return true;
>             if (obj == null)
>                   return false;
>             if (getClass() != obj.getClass())
>                   return false;
>             TestFact other = (TestFact) obj;
>             if (value != other.value)
>                   return false;
>             return true;
>       }     
> }
> The following unit test which attempts to use Verifier.
>       @Test
>       public final void testVerifierOnLiteral()
>       {
>             VerifierBuilder verBuilder  = VerifierBuilderFactory.newVerifierBuilder();
>         Verifier ver = verBuilder.newVerifier();
>         String ruleText = getRuleFromResource(TEST_RULE);
>         ver.addResourcesToVerify( ResourceFactory.newReaderResource( 
>                   new StringReader( ruleText ) ), ResourceType.DRL );
>         
>         Assert.assertTrue(ver.fireAnalysis());       
>       }
> Running the test with JUnit produces the following exception.
> java.lang.RuntimeException: org.drools.RuntimeDroolsException: Exception executing ReturnValue constraint org.drools.rule.ReturnValueRestriction at 589f81 : [Error: cannot convert <1> to a numeric type: class java.lang.Integer [0]]
> [Near : {... Unknown ....}]
>              ^
> [Line: 1, Column: 0]
>                 at org.drools.verifier.builder.VerifierImpl.analyse(VerifierImpl.java:148)
>                 at org.drools.verifier.builder.VerifierImpl.fireAnalysis(VerifierImpl.java:117)
>                 at com.p1s.mps.rulevalidator.NumericConversionTest.testVerifierOnLiteral(NumericConversionTest.java:64)
>                 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
>                 at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>                 at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
>                 at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
>                 at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
>                 at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
>                 at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:73)
>                 at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:46)
>                 at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
>                 at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
>                 at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
>                 at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
>                 at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
>                 at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
>                 at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46)
>                 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)
> Caused by: org.drools.RuntimeDroolsException: Exception executing ReturnValue constraint org.drools.rule.ReturnValueRestriction at 589f81 : [Error: cannot convert <1> to a numeric type: class java.lang.Integer [0]]
> [Near : {... Unknown ....}]
>              ^
> [Line: 1, Column: 0]
>                 at org.drools.rule.ReturnValueConstraint.isAllowedCachedRight(ReturnValueConstraint.java:168)
>                 at org.drools.common.TripleBetaConstraints.isAllowedCachedRight(TripleBetaConstraints.java:211)
>                 at org.drools.reteoo.NotNode.assertObject(NotNode.java:140)
>                 at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
>                 at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:145)
>                 at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:450)
>                 at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:378)
>                 at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:190)
>                 at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:145)
>                 at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1174)
>                 at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1123)
>                 at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:917)
>                 at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:251)
>                 at org.drools.verifier.builder.VerifierImpl.analyse(VerifierImpl.java:136)
>                 ... 26 more
> Caused by: org.drools.RuntimeDroolsException: [Error: cannot convert <1> to a numeric type: class java.lang.Integer [0]]
> [Near : {... Unknown ....}]
>              ^
> [Line: 1, Column: 0]
>                 at org.drools.rule.ReturnValueRestriction.isAllowed(ReturnValueRestriction.java:236)
>                 at org.drools.rule.ReturnValueConstraint.isAllowedCachedRight(ReturnValueConstraint.java:162)
>                 ... 39 more
> Caused by: [Error: cannot convert <1> to a numeric type: class java.lang.Integer [0]]
> [Near : {... Unknown ....}]
>              ^
> [Line: 1, Column: 0]
>                 at org.mvel2.math.MathProcessor.getInternalNumberFromType(MathProcessor.java:577)
>                 at org.mvel2.math.MathProcessor._doOperations(MathProcessor.java:155)
>                 at org.mvel2.math.MathProcessor.doOperations(MathProcessor.java:79)
>                 at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:102)
>                 at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
>                 at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:104)
>                 at org.mvel2.MVEL.executeExpression(MVEL.java:978)
>                 at org.drools.base.mvel.MVELReturnValueExpression.evaluate(MVELReturnValueExpression.java:92)
>                 at org.drools.rule.ReturnValueRestriction.isAllowed(ReturnValueRestriction.java:226)
>                 ... 40 more
> However, if I use the following version of the same rule where I have added parentheses it works.
> package com.simple.test.rule
> import com.p1s.mps.rulevalidator.TestFact;
> rule "TestRule"
> when
>       $fact : TestFact(value == (1))
> then
>       System.out.println($fact.getValue());
> end
> Note that both versions of the DRL file compile, run, and produce the correct results.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 31 14:36:24 2011
From: jira-events at lists.jboss.org (Esteban Aliverti (JIRA))
Date: Sun, 31 Jul 2011 14:36:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Issue Comment Edited: (JBRULES-2800)
 Issue with literals in Drools Verifier 5.1.1
In-Reply-To: <123642794.1719.1289932905646.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1991080075.93676.1312137384207.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617729#comment-12617729 ] 

Esteban Aliverti edited comment on JBRULES-2800 at 7/31/11 2:35 PM:
--------------------------------------------------------------------

Since to be working in 5.2.0.Final.
I have attached a test case. Could you please check it?

      was (Author: eaa):
    Since to be working in 5.2.0.Final.
Could you please check it?
  
> Issue with literals in Drools Verifier 5.1.1
> --------------------------------------------
>
>                 Key: JBRULES-2800
>                 URL: https://issues.jboss.org/browse/JBRULES-2800
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-verifier
>    Affects Versions: 5.1.1.FINAL
>            Reporter: Nathan Bell
>            Assignee: Toni Rikkola
>            Priority: Minor
>         Attachments: JBRULES-2800-testProject.zip
>
>
> I posted this to the "rules-users" list, and did not get a response. That leads me to believe it is a bug, so I'm submitting it here. Below is the text of my email.
> Using org.drools.verifier found in "drools-verifier-5.1.1.jar" I get an org.drools.RuntimeDroolsException if a pattern in a rule LHS contains a comparison to a literal value using the equals operator.
> Please consider the following rule I created solely for the purposes of isolating this issue.
> package com.simple.test.rule
> import com.p1s.mps.rulevalidator.TestFact;
> rule "TestRule"
> when
>       $fact : TestFact(value == 1)
> then
>       System.out.println($fact.getValue());
> end
> The following class definition for the TestFact.
> package com.p1s.mps.rulevalidator;
> public class TestFact 
> {
>       private int value;
>       public TestFact(int value) {
>             this.value = value;
>       }
>       
>       public int getValue() {
>             return value;
>       }
>       public void setValue(int value) {
>             this.value = value;
>       }
>       @Override
>       public int hashCode() {
>             final int prime = 31;
>             int result = 1;
>             result = prime * result + value;
>             return result;
>       }
>       @Override
>       public boolean equals(Object obj) {
>             if (this == obj)
>                   return true;
>             if (obj == null)
>                   return false;
>             if (getClass() != obj.getClass())
>                   return false;
>             TestFact other = (TestFact) obj;
>             if (value != other.value)
>                   return false;
>             return true;
>       }     
> }
> The following unit test which attempts to use Verifier.
>       @Test
>       public final void testVerifierOnLiteral()
>       {
>             VerifierBuilder verBuilder  = VerifierBuilderFactory.newVerifierBuilder();
>         Verifier ver = verBuilder.newVerifier();
>         String ruleText = getRuleFromResource(TEST_RULE);
>         ver.addResourcesToVerify( ResourceFactory.newReaderResource( 
>                   new StringReader( ruleText ) ), ResourceType.DRL );
>         
>         Assert.assertTrue(ver.fireAnalysis());       
>       }
> Running the test with JUnit produces the following exception.
> java.lang.RuntimeException: org.drools.RuntimeDroolsException: Exception executing ReturnValue constraint org.drools.rule.ReturnValueRestriction at 589f81 : [Error: cannot convert <1> to a numeric type: class java.lang.Integer [0]]
> [Near : {... Unknown ....}]
>              ^
> [Line: 1, Column: 0]
>                 at org.drools.verifier.builder.VerifierImpl.analyse(VerifierImpl.java:148)
>                 at org.drools.verifier.builder.VerifierImpl.fireAnalysis(VerifierImpl.java:117)
>                 at com.p1s.mps.rulevalidator.NumericConversionTest.testVerifierOnLiteral(NumericConversionTest.java:64)
>                 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
>                 at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>                 at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
>                 at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
>                 at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
>                 at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
>                 at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:73)
>                 at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:46)
>                 at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
>                 at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
>                 at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
>                 at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
>                 at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
>                 at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
>                 at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46)
>                 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)
> Caused by: org.drools.RuntimeDroolsException: Exception executing ReturnValue constraint org.drools.rule.ReturnValueRestriction at 589f81 : [Error: cannot convert <1> to a numeric type: class java.lang.Integer [0]]
> [Near : {... Unknown ....}]
>              ^
> [Line: 1, Column: 0]
>                 at org.drools.rule.ReturnValueConstraint.isAllowedCachedRight(ReturnValueConstraint.java:168)
>                 at org.drools.common.TripleBetaConstraints.isAllowedCachedRight(TripleBetaConstraints.java:211)
>                 at org.drools.reteoo.NotNode.assertObject(NotNode.java:140)
>                 at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
>                 at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:145)
>                 at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:450)
>                 at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:378)
>                 at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:190)
>                 at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:145)
>                 at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1174)
>                 at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1123)
>                 at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:917)
>                 at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:251)
>                 at org.drools.verifier.builder.VerifierImpl.analyse(VerifierImpl.java:136)
>                 ... 26 more
> Caused by: org.drools.RuntimeDroolsException: [Error: cannot convert <1> to a numeric type: class java.lang.Integer [0]]
> [Near : {... Unknown ....}]
>              ^
> [Line: 1, Column: 0]
>                 at org.drools.rule.ReturnValueRestriction.isAllowed(ReturnValueRestriction.java:236)
>                 at org.drools.rule.ReturnValueConstraint.isAllowedCachedRight(ReturnValueConstraint.java:162)
>                 ... 39 more
> Caused by: [Error: cannot convert <1> to a numeric type: class java.lang.Integer [0]]
> [Near : {... Unknown ....}]
>              ^
> [Line: 1, Column: 0]
>                 at org.mvel2.math.MathProcessor.getInternalNumberFromType(MathProcessor.java:577)
>                 at org.mvel2.math.MathProcessor._doOperations(MathProcessor.java:155)
>                 at org.mvel2.math.MathProcessor.doOperations(MathProcessor.java:79)
>                 at org.mvel2.ast.BinaryOperation.getReducedValueAccelerated(BinaryOperation.java:102)
>                 at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
>                 at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:104)
>                 at org.mvel2.MVEL.executeExpression(MVEL.java:978)
>                 at org.drools.base.mvel.MVELReturnValueExpression.evaluate(MVELReturnValueExpression.java:92)
>                 at org.drools.rule.ReturnValueRestriction.isAllowed(ReturnValueRestriction.java:226)
>                 ... 40 more
> However, if I use the following version of the same rule where I have added parentheses it works.
> package com.simple.test.rule
> import com.p1s.mps.rulevalidator.TestFact;
> rule "TestRule"
> when
>       $fact : TestFact(value == (1))
> then
>       System.out.println($fact.getValue());
> end
> Note that both versions of the DRL file compile, run, and produce the correct results.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 31 16:52:23 2011
From: jira-events at lists.jboss.org (Thomas Segismont (JIRA))
Date: Sun, 31 Jul 2011 16:52:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-206) New JSESSIONID for
 every request in JBossAS7 causing no sticky HttpSession
In-Reply-To: <1516349975.77845.1311369443628.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1302529097.93823.1312145543671.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617743#comment-12617743 ] 

Thomas Segismont commented on JBWEB-206:
----------------------------------------

Hi Robert,

You should have a look at http://community.jboss.org/message/612763#612763

Thomas

> New JSESSIONID for every request in JBossAS7 causing no sticky HttpSession
> --------------------------------------------------------------------------
>
>                 Key: JBWEB-206
>                 URL: https://issues.jboss.org/browse/JBWEB-206
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-7.0.0.CR4
>         Environment: JBossAS 7.0.0.Final server running on a Windows 7 desktop with Oracle/Sun JDK 1.6.0_26.  Issue is occurring with Firefox 5, IE9 and IE8 browsers.
>            Reporter: Robert Baty
>            Assignee: Remy Maucherat
>
> Deploying a JEE application to JBossAS7 when trying to get HttpSession data using request.getSession() a new session is created each time an no data is persisted.  Tracking this down I seem to be seeing a 
> Set-Cookie  JSESSIONID=nTokSr2GnHgUTPZnbMtpgjfS; Version=1; Path="/rjb"
> in every response with no Cookie being maintained for the next request.
> I have tried this on a number of browsers.  It seems to be happening in Firefox 5 and Internet Explorer 8, 9.  I do seem to work with an older Firefox 3.6 browser however.
> After thinking I have something wrong with my browser I deployed the application to JBossAS6 and used the same Firefox 5 browser and am seeing the JSESSIONID being established and session data being maintained between pages in memory.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 31 17:38:23 2011
From: jira-events at lists.jboss.org (Aslak Knutsen (JIRA))
Date: Sun, 31 Jul 2011 17:38:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (AS7-1242) arquillian-service
 is only deployed to first container in group
In-Reply-To: <1378602236.43713.1310337623634.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <1530418481.93834.1312148303732.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aslak Knutsen reassigned AS7-1242:
----------------------------------

    Assignee: Aslak Knutsen


> arquillian-service is only deployed to first container in group
> ---------------------------------------------------------------
>
>                 Key: AS7-1242
>                 URL: https://issues.jboss.org/browse/AS7-1242
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 7.0.0.CR1
>            Reporter: Dan Allen
>            Assignee: Aslak Knutsen
>
> When using the Arquillian group feature with the JBoss AS 7 remote container adapter, the arquillian-service is only deployed to the first container. For an example of the problem, see the multinode example in the Arquillian showcase [1].
> The test only runs if I use servers that already have the arquillian-service deployed.
> http://github.com/arquillian/arquillian-showcase

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 31 18:35:23 2011
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Sun, 31 Jul 2011 18:35:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1072) Cannot use an
 encrypted database password
In-Reply-To: <112206153.10548.1308669563619.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <155323908.93862.1312151723912.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

SBS JIRA Integration updated AS7-1072:
--------------------------------------

    Forum Reference: http://community.jboss.org/message/610516#610516, http://community.jboss.org/message/618489#618489  (was: http://community.jboss.org/message/610516#610516)


> Cannot use an encrypted database password
> -----------------------------------------
>
>                 Key: AS7-1072
>                 URL: https://issues.jboss.org/browse/AS7-1072
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 7.0.0.Beta3
>         Environment: AS7 upstream (June 21 2011)
>            Reporter: Juergen Zimmermann
>            Assignee: Marcus Moyses
>
> I'm using Jenkins build 1241. When I declare datasources in standalone.xml with  <user-name> and <password>, there is no problem.
> However, when I declare a security domain (java:/swe1DS is the datasource's jndi name):
> <security-domain name="verschluesseltesDbPassword" cache-type="default">
> 	<authentication>
> 		<login-module code="SecureIdentity" flag="required">
> 			<module-option name="username" value="swe2"/>
> 			<module-option name="password" value="..."/>
> 			<module-option name="managedConnectionFactoryName" value="jboss.jca:name=swe2DS,service=LocalTxCM"/>
> 		</login-module>
> 	</authentication>
> </security-domain>
> and changed the <security> section inside the datasource definition to
> <security-domain>verschluesseltesDbPassword</security-domain>
> then I get this stacktrace, when JBoss 7 is launched:
> 17:11:33,816 ERROR [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer] (MSC service thread 1-1) Exception during createSubject()Unauthenticated caller:null: java.lang.SecurityException: Unauthenticated caller:null
> 	at org.jboss.security.plugins.JBossSecuritySubjectFactory.createSubject(JBossSecuritySubjectFactory.java:83)
> 	at org.jboss.jca.deployers.common.AbstractDsDeployer$1.run(AbstractDsDeployer.java:979)
> 	at org.jboss.jca.deployers.common.AbstractDsDeployer$1.run(AbstractDsDeployer.java:959)
> 	at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_26]
> 	at org.jboss.jca.deployers.common.AbstractDsDeployer.createSubject(AbstractDsDeployer.java:958)
> 	at org.jboss.jca.deployers.common.AbstractDsDeployer.deployDataSource(AbstractDsDeployer.java:507)
> 	at org.jboss.jca.deployers.common.AbstractDsDeployer.createObjectsAndInjectValue(AbstractDsDeployer.java:246)
> 	at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.deploy(AbstractDataSourceService.java:241)
> 	at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:105)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 31 18:35:24 2011
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Sun, 31 Jul 2011 18:35:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (AS7-1072) Cannot use an
 encrypted database password
In-Reply-To: <112206153.10548.1308669563619.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <7937860.93872.1312151724162.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

SBS JIRA Integration updated AS7-1072:
--------------------------------------

    Forum Reference: http://community.jboss.org/message/610516#610516, http://community.jboss.org/message/618489#618489  (was: http://community.jboss.org/message/610516#610516, http://community.jboss.org/message/618489#618489)


> Cannot use an encrypted database password
> -----------------------------------------
>
>                 Key: AS7-1072
>                 URL: https://issues.jboss.org/browse/AS7-1072
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 7.0.0.Beta3
>         Environment: AS7 upstream (June 21 2011)
>            Reporter: Juergen Zimmermann
>            Assignee: Marcus Moyses
>
> I'm using Jenkins build 1241. When I declare datasources in standalone.xml with  <user-name> and <password>, there is no problem.
> However, when I declare a security domain (java:/swe1DS is the datasource's jndi name):
> <security-domain name="verschluesseltesDbPassword" cache-type="default">
> 	<authentication>
> 		<login-module code="SecureIdentity" flag="required">
> 			<module-option name="username" value="swe2"/>
> 			<module-option name="password" value="..."/>
> 			<module-option name="managedConnectionFactoryName" value="jboss.jca:name=swe2DS,service=LocalTxCM"/>
> 		</login-module>
> 	</authentication>
> </security-domain>
> and changed the <security> section inside the datasource definition to
> <security-domain>verschluesseltesDbPassword</security-domain>
> then I get this stacktrace, when JBoss 7 is launched:
> 17:11:33,816 ERROR [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer] (MSC service thread 1-1) Exception during createSubject()Unauthenticated caller:null: java.lang.SecurityException: Unauthenticated caller:null
> 	at org.jboss.security.plugins.JBossSecuritySubjectFactory.createSubject(JBossSecuritySubjectFactory.java:83)
> 	at org.jboss.jca.deployers.common.AbstractDsDeployer$1.run(AbstractDsDeployer.java:979)
> 	at org.jboss.jca.deployers.common.AbstractDsDeployer$1.run(AbstractDsDeployer.java:959)
> 	at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_26]
> 	at org.jboss.jca.deployers.common.AbstractDsDeployer.createSubject(AbstractDsDeployer.java:958)
> 	at org.jboss.jca.deployers.common.AbstractDsDeployer.deployDataSource(AbstractDsDeployer.java:507)
> 	at org.jboss.jca.deployers.common.AbstractDsDeployer.createObjectsAndInjectValue(AbstractDsDeployer.java:246)
> 	at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer.deploy(AbstractDataSourceService.java:241)
> 	at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:105)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 31 20:04:23 2011
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Sun, 31 Jul 2011 20:04:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (AS7-1433) CNFE for Hibernate
 4.0.0.Beta4: org.hibernate.hql.internal.ast.HqlToken
In-Reply-To: <1068095752.93311.1312007304082.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2027396844.93889.1312157063762.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617749#comment-12617749 ] 

Scott Marlow commented on AS7-1433:
-----------------------------------

I would like to recreate the failure in a unit test, so we can make sure it gets resolved.  Do you have the query that is being executed, at the time of the error?  Perhaps I could paste it into an unit test and recreate the failure.  With that, we could use either a debugger or JBoss Byteman (http://www.jboss.org/byteman) to show the original ClassNotFoundException.

Do you know if this worked correctly with AS 7.0.0.Final?

> CNFE for Hibernate 4.0.0.Beta4: org.hibernate.hql.internal.ast.HqlToken
> -----------------------------------------------------------------------
>
>                 Key: AS7-1433
>                 URL: https://issues.jboss.org/browse/AS7-1433
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 7.0.0.Final
>         Environment: Jenkins build 1460
>            Reporter: Juergen Zimmermann
>            Assignee: Scott Marlow
>             Fix For: 7.0.1.Final
>
>
> I switched to Jenkins build 1460 which has Hibernate 4.0.0.Beta4. Now I'm getting the stacktrace below saying that org.hibernate.hql.internal.ast.HqlToken is not found. However, this class is in modules/org/hibernate/main/hibernate-core-4.0.0.Beta4.jar.
> 08:17:22,282 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/swaREST].[javax.ws.rs.core.Application]] (http--127.0.0.1-8080-1) Servlet.service() for servlet javax.ws.rs.core.Application threw exception: org.jboss.resteasy.spi.UnhandledException: javax.ejb.EJBTransactionRolledbackException: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.unwrapException(SynchronousDispatcher.java:345) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:321) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:214) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:190) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:534) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:496) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.AsynchronousDispatcher.invoke(AsynchronousDispatcher.java:243) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:119) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:722) [:1.7.0]
> Caused by: javax.ejb.EJBTransactionRolledbackException: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:158)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:237)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.required(CMTTxInterceptor.java:363)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:219)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:35)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
> 	at de.swa.kundenverwaltung.service.Kundenverwaltung$$$view74.findKundenByNachname(Unknown Source) [swaEJB.jar:]
> 	at de.swa.kundenverwaltung.rest.KundenverwaltungResourceImpl.findKunden(KundenverwaltungResourceImpl.java:94) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
> 	at de.swa.util.LogInterceptor.log(LogInterceptor.java:79) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:45) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$ComponentDispatcherInterceptor.processInvocation(ViewDescription.java:202)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:257)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.required(CMTTxInterceptor.java:359)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:219)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:35)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:146)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:76)
> 	at de.swa.kundenverwaltung.rest.KundenverwaltungResource$$$view76.findKunden(Unknown Source) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:255) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:220) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:209) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:519) [resteasy-jaxrs-2.2.1.GA.jar:]
> 	... 21 more
> Caused by: java.lang.IllegalArgumentException: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1331)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1277)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:497)
> 	at org.hibernate.ejb.criteria.CriteriaQueryCompiler.compile(CriteriaQueryCompiler.java:227)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:614)
> 	at org.jboss.as.jpa.container.AbstractEntityManager.createQuery(AbstractEntityManager.java:126) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at de.swa.kundenverwaltung.service.Kundenverwaltung.findKundenByNachname(Kundenverwaltung.java:138) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:370)
> 	at de.swa.util.LogInterceptor.log(LogInterceptor.java:79) [swaEJB.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.7.0]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.7.0]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.7.0]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [:1.7.0]
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:45) [jboss-as-jpa-7.1.0.Alpha1-SNAPSHOT.jar:7.1.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewDescription$ComponentDispatcherInterceptor.processInvocation(ViewDescription.java:202)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287)
> 	at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
> 	at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:233)
> 	... 86 more
> Caused by: org.hibernate.QueryException: ClassNotFoundException: org.hibernate.hql.internal.ast.HqlToken [select distinct generatedAlias0 from de.swa.bestellverwaltung.domain.Bestellung as generatedAlias0 left join fetch generatedAlias0.lieferungen as generatedAlias1 where ( generatedAlias0.id=11L ) or ( generatedAlias0.id=12L ) or ( generatedAlias0.id=13L ) or ( generatedAlias0.id=14L )]
> 	at org.hibernate.hql.internal.ast.HqlLexer.panic(HqlLexer.java:78)
> 	at antlr.CharScanner.setTokenObjectClass(CharScanner.java:338)
> 	at org.hibernate.hql.internal.ast.HqlLexer.setTokenObjectClass(HqlLexer.java:52)
> 	at antlr.CharScanner.<init>(CharScanner.java:49)
> 	at antlr.CharScanner.<init>(CharScanner.java:58)
> 	at org.hibernate.hql.internal.antlr.HqlBaseLexer.<init>(HqlBaseLexer.java:54)
> 	at org.hibernate.hql.internal.antlr.HqlBaseLexer.<init>(HqlBaseLexer.java:51)
> 	at org.hibernate.hql.internal.antlr.HqlBaseLexer.<init>(HqlBaseLexer.java:48)
> 	at org.hibernate.hql.internal.ast.HqlLexer.<init>(HqlLexer.java:47)
> 	at org.hibernate.hql.internal.ast.HqlParser.getInstance(HqlParser.java:67)
> 	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.parse(QueryTranslatorImpl.java:262)
> 	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:180)
> 	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:136)
> 	at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:101)
> 	at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:80)
> 	at org.hibernate.engine.query.spi.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:120)
> 	at org.hibernate.internal.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:214)
> 	at org.hibernate.internal.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:192)
> 	at org.hibernate.internal.SessionImpl.createQuery(SessionImpl.java:1527)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:479)
> 	... 121 more

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 31 21:19:23 2011
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Sun, 31 Jul 2011 21:19:23 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (AS7-1377) RA logs under
	"datasources"
In-Reply-To: <2002395954.76063.1311337883621.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <2045551163.93909.1312161563747.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Zhang resolved AS7-1377.
-----------------------------

    Fix Version/s: 7.0.1.Final
                       (was: 7.1.0.CR1)
       Resolution: Done


> RA logs under "datasources"
> ---------------------------
>
>                 Key: AS7-1377
>                 URL: https://issues.jboss.org/browse/AS7-1377
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Heiko Braun
>            Assignee: Jeff Zhang
>             Fix For: 7.0.1.Final
>
>
> See ResourceAdaptersExtension.java
> > private static final Logger log = Logger.getLogger("org.jboss.as.datasources");

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

From jira-events at lists.jboss.org  Sun Jul 31 23:18:24 2011
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Sun, 31 Jul 2011 23:18:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-1894) Transaction
 Rollback during client failover may cause duplicated message
Message-ID: <452597359.93975.1312168704100.JavaMail.tomcat@jira02.app.mwc.hst.phx2.redhat.com>

Transaction Rollback during client failover may cause duplicated message
------------------------------------------------------------------------

                 Key: JBMESSAGING-1894
                 URL: https://issues.jboss.org/browse/JBMESSAGING-1894
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Clustering
    Affects Versions: 1.4.8.SP2, 1.4.0.SP3.CP14
            Reporter: Yong Hao Gao
            Assignee: Yong Hao Gao
             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP3


The following scenario shows how a duplicated message is produced:

1. A cluster of two nodes, node 1 and node 2, is up and running.
2. a message is delivered from node 1 to a consumer who receives it in a transaction.
3. for some reason the transaction is rolled back, in which the transaction is first removed from the resource manager and then redelivers the message.
4. At the same time failover happens (node 1 dead), in which it will collect the ACK list from resource manager and recover them to the new node (node 2).
5. because lack of synchronization, if in step 3 after the tx is removed and the message is re-delivered (locally) to the consumer, but before the tx is committed, the fail over happens and it won't get the message's ACK info ('cos the tx has been removed already) and the message will be failed over to node 2 and redelivered.

6. So with the successful commit of the tx, the same message is delivered twice.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

